☰

Медленная синхронизация Fsync с локальным SSD Google Cloud (Postgresql)

tag-icon • tag-icon postgresql google-compute-engine
Медленная синхронизация Fsync с локальным SSD Google Cloud (Postgresql)

Я получаю неожиданно низкое количество транзакций в секунду на опции GCE «Local SSD» (по сравнению с SSD Persistent Disk) при использовании простых тестов «pgbench»:

# With Local SSD
# /dev/mapper/vg0-data on /data type xfs (rw,noexec,noatime,attr2,inode64,noquota)
pg-dev-002:~$ pgbench -c 8 -j 2 -T 60 -U postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 8
number of threads: 2
duration: 60 s
number of transactions actually processed: 10765
tps = 179.287875 (including connections establishing)
tps = 179.322407 (excluding connections establishing)

# With SSD Persistent Disk
# /dev/mapper/vg1-data on /data1 type xfs (rw,noexec,noatime,attr2,inode64,noquota)
pg-dev-002:/data$ pgbench -c 8 -j 2 -T 60 -U postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 8
number of threads: 2
duration: 60 s
number of transactions actually processed: 62457
tps = 1040.806664 (including connections establishing)
tps = 1041.012782 (excluding connections establishing)

Тесты "fio" показывают заявленные IOPS и пропускную способность для локального SSD. Однако выполнение "pg_test_fsync" на локальном SSD-накопителе заставляет меня думать, что виновата задержка fsync. Цифры локального SSD получены после применения скрипта IRQ Googleздесь:

# Local SSD
open_datasync                     319.738 ops/sec    3128 usecs/op
fdatasync                         321.963 ops/sec    3106 usecs/op

# Persistent SSD
open_datasync                    1570.305 ops/sec     637 usecs/op
fdatasync                        1561.469 ops/sec     640 usecs/op
  • Протестировано с образами Ubuntu 14.04 и Debian 7
  • Тип экземпляра: n1-highmem-4
  • Параметры монтирования идентичны для обоих типов томов.

Я не видел ничего об ограничениях fsync и локального SSD, но не знаю, где еще это можно проверить или протестировать.

решение1

Сравниваяодинокийлокальные SSD/HDD и т. д. с RAID-контроллером типа SAN — это как сравнивать VW Beetle и автомобиль Audi RS10 Le-Man. Да, они оба вышли на одном заводе, и оба используют четырехтактные двигатели/SSD/HDD, но их настройки и т. д. сильно различаются.

Я могу привести вам несколько примеров полученного опыта, но простые ответы связаны с огромными объемами кэша RAM с резервным питанием от батареи, который есть у хранилища на основе SAN по сравнению с нелокальным SSD/HDD. Даже SSD не могут конкурировать с резервным питанием от батареи DDR3 RAM, когда дело доходит до подтверждения того, что данные были «зафиксированы» на диске. Более того, один локальный диск может (реально) обрабатывать только одну операцию за раз, записывая блок на «диск», в отличие от резервных систем SAN, которые могут обрабатывать несколько запросов одновременно «записывать на диск» (поскольку они фиксируют данные в резервном питании от батареи DDR3 RAM).

Наконец, вопрос может быть таким:которыйиспользуются локальные SSD-диски, так как я заметил огромную разницу в производительности записи между различнымиразмерыодного и того же семейства SSD-накопителей (чем больше, тем быстрее), не говоря уже о различных скоростях различных моделей SSD-дисков.

ДА, SSD быстрее HDD, но пока не так быстры, как оперативная память DDR3 с питанием от батареи ;)

решение2

Google признает, что очистка кэша записи происходит довольно медленно на локальном SSD и предоставляет шаги по отключению кэширования записи при монтировании файловой системы, чтобы избежать этой задержки [если это подходит для вашего варианта использования]. Документыздесь.

Связанный контент