Как стать автором
Обновить

PostgreSQL на разных фс (ext3, ext4, xfs)

Время на прочтение 2 мин
Количество просмотров 32K


Статья — заметка, выросшая из вопроса, заданного в 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. Андрей Фефелов, привет!!! )))
Теги:
Хабы:
+36
Комментарии 50
Комментарии Комментарии 50

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн