Slovak Sun Training Day 2010 - OpenSolarisMartin Cerveny
Presentation from training day for Sun Solaris customers to explain new features of OpenSolaris.
Presentation covers following themes:
- installation
- software packaging - IPS
- network virtualization - crossbow
- SCSI target - COMSTAR
Czech Oracle Solaris Administrators Day 2011 - Solaris Express (OpenSolaris)Martin Cerveny
Presentation from training day for Oracle Solaris customers to explain new features of Solaris Express (OpenSolaris).
Presentation covers following themes:
- installation
- software packaging - IPS
- network virtualization - crossbow
- SCSI target - COMSTAR
Demolabs: http://www.edumaster.cz/java-developers-solaris-administrators-day/pdf/jsd2011_solex11_labs.tar.gz
Openstack Newton
Zdeněk Janda, CTO Cloudinfrastack
Představení poslední verze Openstack Newton v kostce. Novinky v možnostech jednotlivých Openstack služeb, vysoká dostupnost, distribuovaná storage Ceph, orchestrace a Docker kontejnery. Deployment Openstacku a monitoring. Praktické zkušenosti a live demo.
Slovak Sun Training Day 2010 - OpenSolarisMartin Cerveny
Presentation from training day for Sun Solaris customers to explain new features of OpenSolaris.
Presentation covers following themes:
- installation
- software packaging - IPS
- network virtualization - crossbow
- SCSI target - COMSTAR
Czech Oracle Solaris Administrators Day 2011 - Solaris Express (OpenSolaris)Martin Cerveny
Presentation from training day for Oracle Solaris customers to explain new features of Solaris Express (OpenSolaris).
Presentation covers following themes:
- installation
- software packaging - IPS
- network virtualization - crossbow
- SCSI target - COMSTAR
Demolabs: http://www.edumaster.cz/java-developers-solaris-administrators-day/pdf/jsd2011_solex11_labs.tar.gz
Openstack Newton
Zdeněk Janda, CTO Cloudinfrastack
Představení poslední verze Openstack Newton v kostce. Novinky v možnostech jednotlivých Openstack služeb, vysoká dostupnost, distribuovaná storage Ceph, orchestrace a Docker kontejnery. Deployment Openstacku a monitoring. Praktické zkušenosti a live demo.
Implementace Openstacku v LMC – představy vs. realita Jaroslav Jacjuk
Michal Rychlík, System Administrator LMC
Proč jsme se rozhodli jít cestou cloudu namísto vlastního HW? Jaká byla naše původní očekávání a jaká pak byla skutečnost? Jaké jsou problémy, na které jsme při implementaci narazili a stále narážíme? O to vše se rád s vámi podělím.
Přehled variant databázové replikace (master-slave vs. master-master, physical vs. logical) a jejich pro a proti. Krátká historie replikace v PostgreSQL s přehled nástrojů které dnes máme k dispozici (slony-I, pgpool-II, Londiste a Bucardo). A nakonec stručné srovnání s replikací ve dvou populárních databázích (MySQL a Oracle).
Red Hat Storage Server presentation - online presentation for ELOS Technologies customers and for all who would like to attend online. Video in Czech language will be available in few days.
Oracle Solaris Day 2013 - Oracle DB and OS SolarisMartin Cerveny
Presentation from training day for Oracle Solaris customers to explain advantages of running Oracle Database on Oracle Solaris.
Presentation covers following themes:
- system and network virtualization
- filesystem ZFS
- security with RBAC
- running with SMF
- tuning with DTrace
Demo labs: http://www.slideshare.net/m_cerveny/osd2013-cmd
Czech Sun Training Day 2008 - Java Enterprise SystemMartin Cerveny
Presentation from training day for Sun Solaris customers to explain features of Sun Java Enterprise System.
Presentation covers following themes:
- architecture
- Directory server
- Web server
- Access manager
- Portal server
node.js: zápisky z fronty (Battle guide to node.js)almadcz
[czech] V Apiary používáme node.js v produkci už přes rok.
Proč se zamyslet nad tím, zda ho chcete? A na co se připravit a na co si dát pozor, pokud se do toho pustíte?
Presentation from training day for Sun Solaris customers to explain some important features of Solaris 10.
Presentation covers following themes:
- Solaris and virtualization (XEN, VirtualBox, LDom, zones)
- Solaris and production (ZFS, DTrace)
- Solaris and security (privileges, trusted extension)
Implementace Openstacku v LMC – představy vs. realita Jaroslav Jacjuk
Michal Rychlík, System Administrator LMC
Proč jsme se rozhodli jít cestou cloudu namísto vlastního HW? Jaká byla naše původní očekávání a jaká pak byla skutečnost? Jaké jsou problémy, na které jsme při implementaci narazili a stále narážíme? O to vše se rád s vámi podělím.
Přehled variant databázové replikace (master-slave vs. master-master, physical vs. logical) a jejich pro a proti. Krátká historie replikace v PostgreSQL s přehled nástrojů které dnes máme k dispozici (slony-I, pgpool-II, Londiste a Bucardo). A nakonec stručné srovnání s replikací ve dvou populárních databázích (MySQL a Oracle).
Red Hat Storage Server presentation - online presentation for ELOS Technologies customers and for all who would like to attend online. Video in Czech language will be available in few days.
Oracle Solaris Day 2013 - Oracle DB and OS SolarisMartin Cerveny
Presentation from training day for Oracle Solaris customers to explain advantages of running Oracle Database on Oracle Solaris.
Presentation covers following themes:
- system and network virtualization
- filesystem ZFS
- security with RBAC
- running with SMF
- tuning with DTrace
Demo labs: http://www.slideshare.net/m_cerveny/osd2013-cmd
Czech Sun Training Day 2008 - Java Enterprise SystemMartin Cerveny
Presentation from training day for Sun Solaris customers to explain features of Sun Java Enterprise System.
Presentation covers following themes:
- architecture
- Directory server
- Web server
- Access manager
- Portal server
node.js: zápisky z fronty (Battle guide to node.js)almadcz
[czech] V Apiary používáme node.js v produkci už přes rok.
Proč se zamyslet nad tím, zda ho chcete? A na co se připravit a na co si dát pozor, pokud se do toho pustíte?
Presentation from training day for Sun Solaris customers to explain some important features of Solaris 10.
Presentation covers following themes:
- Solaris and virtualization (XEN, VirtualBox, LDom, zones)
- Solaris and production (ZFS, DTrace)
- Solaris and security (privileges, trusted extension)
Czech and Slovak Sun Training Day 2007 - SolarisMartin Cerveny
Presentation from training day for Sun Solaris customers to explain new features of Solaris 10 and OpenSolaris,
Presentation covers following themes:
- installation with Wanboot and JASS (SST - Solaris Security Toolkit)
- kernel privileges and RBAC
- SMF starting service
- DTrace overview
- Solaris Zone
- ZFS filesystem
- OpenSolaris project and community
CREATE STATISTICS - What is it for? (PostgresLondon)Tomas Vondra
CREATE STATISTICS command was introduced in PostgreSQL 10, and improved in PostgreSQL 12. Let's see what queries it's meant to improve and how it works.
Let's discuss the various sources of data corruption in databases (and in PostgreSQL in general) - cosmic rays, storage, bugs in the OS, database or application. I'll share some general observations about those various sources, and also some recommendations how to detect those issues in PostgreSQL (data checksums, ...) and how to deal with them.
The document discusses different approaches to storing sensitive data like credit card numbers in a database. It compares using full-disk encryption versus application-level encryption. Full-disk encryption protects against theft but prevents indexing and queries on encrypted fields. Application-level encryption requires decrypting and re-encrypting all data, moving processing to the application. The document proposes a solution of using a separate trusted component that can compare encrypted values to enable indexing and aggregation while keeping data encrypted in the database.
PostgreSQL performance improvements in 9.5 and 9.6Tomas Vondra
The document summarizes performance improvements in PostgreSQL versions 9.5 and 9.6. Some key improvements discussed include optimizations to sorting, hash joins, BRIN indexes, parallel query processing, aggregate functions, checkpoints, and freezing. Performance tests on sorting, hash joins, and parallel queries show significant speedups from these changes, such as faster sorting times and better scalability with parallel queries.
PostgreSQL na EXT4, XFS, BTRFS a ZFS / FOSDEM PgDay 2016Tomas Vondra
The document provides an overview of different file systems for PostgreSQL including EXT3/4, XFS, BTRFS and ZFS. It discusses the evolution and improvements made to EXT3/4 and XFS over time to address scalability, bugs and new storage technologies like SSDs. BTRFS and ZFS are described as designed for large data volumes and built-in features like snapshots and checksums but BTRFS is still considered experimental. Benchmark results show ZFS and optimized EXT4/XFS performing best and BTRFS performance significantly reduced due to copy-on-write. The conclusion recommends EXT4/XFS for traditional needs and ZFS for advanced features, avoiding BTRFS.
PostgreSQL on EXT4, XFS, BTRFS and ZFSTomas Vondra
One of the most common question I'm asked by users and customer about configuring a Linux-based system for PostgreSQL is "What file fystem should I use to get the best performance?" Sadly, most of the recommendations is based on obsolete "common knowledge" passed from generation to generation. But in recent years the file systems improved a lot - we've seen both evolution of established file systems (EXT family, XFS, ...) and revolution in the form of BTRFS, ZFS or F2FS. And of course new kinds of hardware (SSDs) which certainly impacts the design of a file system.
Performance improvements in PostgreSQL 9.5 and beyondTomas Vondra
This document discusses several performance improvements made in PostgreSQL versions 9.5 and beyond. Some key improvements discussed include:
- Faster sorting through allowing sorting by inlined functions, abbreviated keys for VARCHAR/TEXT/NUMERIC, and Sort Support benefits.
- Improved hash joins through reduced palloc overhead, smaller NTUP_PER_BUCKET, and dynamically resizing the hash table.
- Index improvements like avoiding index tuple copying, GiST and bitmap index scan optimizations, and block range tracking in BRIN indexes.
- Aggregate functions see speedups through using 128-bit integers for internal state instead of NUMERIC in some cases.
- Other optimizations affect PL/pgSQL performance,
The document summarizes performance benchmarks comparing PostgreSQL versions from 7.4 to the latest version. The benchmarks show significant performance improvements across different workloads over time, including:
- Up to 6x faster transaction processing rates in pgbench
- Much better scalability to multiple cores and clients
- 6x faster query times for TPC-DS data warehouse benchmark
- Over 10x speedup for some full text search queries in latest version
The benchmarks demonstrate that PostgreSQL has become dramatically faster and more scalable over the past 10+ years, while also using less disk space and memory.
Standardní implementace ispell slovníků v PostgreSQL má bohužel několik nevýhod co se CPU a paměti týká. Napsal jsem extension která umožňuje slovníky inicializovat jen jednou a sdílet je mezi spojeními.
Jaký dopad na výkon má přesun transakčního logu nebo indexů na samostatný disk? Jak výsledek závisí na typu workloadu (OLTP vs. DWH) a na typu disku (HDD vs. SSD)?
Stručný úvod do čtení explain planu - seznámení s principem jak databáze vybírá postup vyhodnocení dotazu, na jaké základní operace v něm můžeme narazit (varianty čtení tabulek a joinů). Zejména se ale podíváme na to jak identifikovat problematická místa v exekučním plánu, v čem může být příčina a jak ji odstranit.
Prezentace připravená pro konferenci Prague PostgreSQL Developers' Day 2010. Hlavním tématem je monitoring výkonu PostgreSQL databázového serveru, nástrojů které k tomu lze použít, atd. Na začátku jsou představeny základní pojmy (např. co je to snapshot), a poté je předvedeno několik užitečných nástrojů (jeden z nich vyvíjím já).
1. Pohádka o checkpointu
Co se děje při checkpointu, možnosti a ladění.
CSPUG Praha, 22. 11. 2011
Tomáš Vondra, tv@fuzzy.cz
2. Co je to checkpoint?
činnost nutná kvůli samostatnému transakčnímu logu (WAL)
1) načtení dat do shared buffers
WAL
2) zápis do WAL (disk) 2 3
WAL
3) úprava shared buffers (RAM) shared buffers
WAL
4) sync dat ve WAL (commit)
WAL
5) checkpoint (zápis dat) 4 1 5
disk
nejčastější problém u databází s netriviálním počtem změn
ne zcela jednoduchý monitoring a určení příčiny problému
interakce s operačním systémem (pdflush v Linuxu apod)
3. Kdy k checkpointu dochází?
po vyčerpání počtu transakčních logů (xlog)
checkpoint_segments = 64
po vypršení časového limitu (timed)
checkpoint_timeout = 5m
na vyžádání uživatele
CHECKPOINT
4. Interakce s OS (Linux)
je to trochu složitější kvůli interakci s OS
operační systémy vesměs mají cache pro disky (page cache)
výhody cache – opakovaný zápis, řazení zápisů (sekvenční)
zápis na disk až při fsync
WAL
Linux – pdflush (/proc/sys/vm) WAL
shared buffers
☐ dirty_background_ratio WAL
☐ dirty_ratio WAL
☐ dirty_expire_centisecs page cache
disk
http://www.westnet.com/~gsmith/content/linux-pdflush.htm
5. page cache v Linuxu
vm.dirty_background_ratio
☐ „dirty“ limit než pdflush začne zapisovat na pozadí
☐ bývalo 10%, dnes 5%
vm.dirty_ratio
☐ „dirty“ limit než procesy musí zapisovat přímo (bez cache)
☐ bývalo 40%, dnes 10%
vm.dirty_expire_centisecs
☐ timeout jak dlouho smí být „dirty“ data v cache
☐ standardně 30s
6. interakce s page cache
příklad: server s 16GB paměti (dnes víceméně minimum)
4 GB - shared buffers
1 GB - OS + různé blbosti
11 GB – page cache (maximum)
☐ dirty_background_ratio = 5% = 560 MB*
☐ dirty_ratio = 10% = 1020 MB*
To by pro slušný řadič / diskové pole neměl být problém, ne?
* počítá se z (MemFree + Cached – Mapped) – viz. /proc/meminfo
7. interakce s page cache (2)
řekněme že zapíšete 1GB dat …
ve skutečnosti musíte zapsat > 2GB
☐ 1GB data, 1GB pro WAL, overhead (metadata)
různá povaha zápisů
☐ do WAL sekvenčně
☐ datových souborů (CHECKPOINT) mix (náhodně + sekvenčně)
standardní 7.2k SATA disk zvládne zhruba zápis
☐ 60MB/s sekvenčně
☐ 0.5MB/s náhodně
14. stupňování problémů s page cache
1. zapisujete velký objem dat (např. noční load / batch)
2. dosáhnete dirty_background_ratio
pdflush začne zapisovat na disk
DB zapisuje do page cache
disk nestíhá čistit cache
3. dosáhnete dirty_ratio
pdflush zapisuje na disk
DB musí zapisovat přímo na disk (bez cache)
4. peklo
15. Ladění checkpointů
page cache, databáze, aplikace ...
Hardware people always seem convinced that any problem can be fixed by
more complex software (software people, in contrast, know that problems
can always be solved by more hardware).
[TheRaven64 @ slashdot.org]
16. Ladění …
latence vs. propustnost
☐ latence – reakce na jednotlivé požadavky
☐ propustnost – celkový počet požadavků
☐ většinou nemůžete mít oboje :-(
cíle snahy
☐ nenutit DB k checkpointu příliš často (kumulace změn)
☐ když už je nutný checkpoint, tak postupný (spread)
☐ omezení množství zápisů (vhodnou úpravou algoritmu, MVCC)
☐ eliminace „šoku“ page cache (náhle zápis velkého objemu)
17. informace o checkpointech
log_checkpoints = on
první co byste měli udělat
základní informace (interval, kolik bufferů, trvání sync)
umožňuje korelovat data oproti jiným datům (běžel checkpoint?)
pg_stat_bgwriter
agregovaná data (kolik checkpointů jakého typu, kolik bufferů)
ideální pro sběr snapshotů (kolik snapshotů za hodinu apod.)
informace i o dalších zdrojích zápisů (bgwriter, backendy)
19. operační systém
souborový systém s rozumným fsync chováním
☐ měl by umět fsync na úrovni souborů
☐ xfs, ext4, …
snížení „dirty“ limitů (menší objemy, častěji)
☐ dirty_background_ratio = 2 (viděl jsem i 0)
☐ dirty_ratio = 5
☐ dirty_expire_centisecs = 500 (5 vteřin)
☐ případně „_bytes“ varianty (po upgrade RAM stále platí)
21. segments / timeout
checkpoint_segments = 3
výchozí hodnota je velmi nízká (jen 48MB dat)
zvýšení omezí frekvenci „xlog“ checkpointů (není místo ve WAL)
checkpoint_timeout = 5 min
zvýšení maximální doby mezi checkpointy (maximum 1h)
důsledky zvýšení
možnost opakované modifikace bloku mezi checkpointy (snížení I/O)
prodloužení recovery v případě pádu (aplikace WAL segmentů od posledního
checkpointu)
22. completion_target
checkpoint_completion_target
před verzí 8.3 se při checkpointu jelo „na plný plyn“ (hodně I/O)
nově se zápisy rozloží na dobu dalšího checkpointu (timed i xlog)
příklad
vypršel timeout (5 minut), 540 MB dat k zápisu (v shared buffers)
completion_target * timeout = 0.9 * 300s = 270s (konec zápisu)
540 MB / 270 s = 2 MB/s (průměrná rychlost)
důsledky
zvýšení počtu segmentů (cca na dvojnásobek)
24. wal_level
ne vždy je třeba „wal_level = archive“
☐ nemáte standby
☐ nechcete PITR (Point-In-Time-Recovery)
„wal_level = minimal“ omezí objem WAL (u některých operací)
☐ CREATE TABLE AS
☐ CREATE INDEX
☐ CLUSTER
☐ COPY (do nové tabulky – i partition je tabulka)
může velmi výrazně zlepšit load dat apod.
☐ ostatní transakce novou relaci nevidí
☐ data jdou přímo na disk (ne do buffers)
25. shared_buffers
občas se doporučuje zmenšit shared buffers (méně dat k zápisu)
☐ spíše zastaralá (pre-8.3) alternativa k spread checkpointům
☐ kombinace s agresivní konfigurací bgwriteru
☐
http://www.westnet.com/~gsmith/content/postgresql/chkp-bgw-83.htm
při čtení to většinou nevadí (díky page cache)
při zápisu může mít negativní důsledky
☐ backendy jsou nuceny zapisovat data samy (tj. iowait)
☐ projevuje se jako růst pg_stat_bgwriter.buffers_backend
26. shared_buffers
moje doporučení (>= 8.3)
1. nastavit konzervativní hodnotu
2. postupně zvyšovat a sledovat výkon
cache „hit ratio“ (bohužel bez page cache)
výkon aplikace (ideální metrika)
3. zastavit jakmile výkon přestane růst
4. případně agresivnější bgwriter (snížení hodnot backend_clean)
5. v každém kroku jen jedna změna
minimální velikost shared buffers, maximální efektivita
27. Ladění … hardware
řadič s write cache
nejlépe s baterkou (ale dle libosti)
cache má omezenou velikost, nezvládne všechno
spread checkpointy výrazně zlepšují (menší objemy, průběžně)
28. Ladění … hardware
SSD
víceméně řeší problém s náhodným přístupem (čtení vs. zápisy)
omezený počet zápisů (problémy s checkpointy => write-heavy db)
dražší (?)
spolehlivost (?)