Статья — заметка, выросшая из вопроса, заданного в Q&A. Вкратце дело было так… Был предложен вариант тестирования PostgreSQL на определенной файловой системе и стоял вопрос, нормальный ли это подход и можно ли хоть как-то доверять результатам этого теста. В ходе обсуждения вопроса альтернативных вариантов не нашлось и я решил тестировать как и задумал изначально.
Собственно, что было и как все проходило:
Есть средненький сервер следующей комплектации:
- HP Proliant DL160 G5
- 1x Intel Xeon CPU E5405 @ 2.00GHz (L1 128KiB, L2 12MiB)
- 4x FB-DIMM DDR2 Synchronous 667 MHz (1.5 ns) итого 8GB RAM
- RAID LSI SAS1064E 4-Port PCI-E 3Gb/s
- 4x SAS HP DF146BABUE 146GB 3.5" LFF 3G 15K RPM
- Gentoo Linux kernel-3.7.1, glibc-2.15-r3, gcc-4.5.4
- PostgreSQL Server 9.2.1
Из четырех дисков было собрано два RAID1, на одном из них размещена операционная система, второй том является полигоном для испытаний. Этот диск используется в качестве LVM PV и для теста выделен LVM том размером 55GB. Тест проходит следующим образом:
- форматируем том и монтируем в каталог;
- запускаем инициализацию postgresql-кластера;
- копируем в кластер заранее подготовленный конфигурационный файл postgresql.conf;
- запускаем postgresql и создаем тестовую базу pgbench;
- запускаем инициализацию таблиц с помощью pgbench;
- циклически в режиме «SELECT's only» запускаем pgbench с разным количество клиентских подключений, результаты сохраняем (каждый тест длится 2 часа)
- циклически в режиме "TPC-B" запускаем pgbench с разным количество клиентских подключений, результаты сохраняем (каждый тест длится 2 часа).
Количество клиентов в каждом тесте вариируется от 8 до 96 (8,16,32,64,96)
Итого для одной файловой системы мы получим 10 результатов (5 SELECT's only, 5 TPC-B)
Несколько деталей, имеющих значение:
- RAID работает без WriteCache;
- все процессы/сервисы были остановлены/выключены за исключением PostgreSQL, таблица процессов практически пуста (за исключением ядерных процессов);
- WAL журналы живут на том же разделе что и данные;
- тестовая база инициализировалась таким образом, чтобы занять 80% пространства всего диска;
- перед каждым запуском pgbench выполнялся сброс кэшей.
Настройки postgresql.conf
max_connections = 100
shared_buffers = 1500MB
work_mem = 16MB
maintenance_work_mem = 128MB
effective_io_concurrency = 1
checkpoint_segments = 32
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9
Результаты для «SELECT's only» и TPC-B
Выводы: вобщем как и ожидалось прорывных и революционных разрывов в результатах нет, все файловые системы вобщем имеют приблизительно одинаковый уровень производительности. Если же приглядываться, то можно отметить несколько моментов:
— ext4 показывает чуть большую производительность чем ext3 (в среднем на 1-3%);
— ext4 показывает наибольшую производительность в TPC-B тесте (от 1% до 8%);
— xfs показывает наибольшую производительность в SELECT's only (от 1% до 3%);
В целом можно сказать «а можно ставить любую фс, разница настолько мала, что ею можно пренебречь». Но помните что (тут можно вставить любую пафосную фразу про важность мелочей). В общем, не пренебрегайте мелочами))
На этом все. Можно
P.S. Андрей Фефелов, привет!!! )))
