Контекст: Я использую Toshiba 512 ГБ NVMe (модель: KXG50ZNV512G)
Я наблюдаю это странное поведение при тестировании Postgres на ZFS-on-Linux (через pgbench), где второй и третий прогоны теста постепенно медленнее, чем первый прогон.
Вот что происходит:
client=1 | 770 => 697 | 10% reduction in TPS
client=4 | 2717 => 2180 | 24% reduction in TPS
client=8 | 4579 => 3339 | 37% reduction in TPS
client=12 | 4219 => 4175 | 01% reduction in TPS
client=48 | 5902 => 5623 | 05% reduction in TPS
client=96 | 7094 => 6739 | 05% reduction in TPS
Я повторно запускаю эти тесты, и ранние цифры показывают, что 3-й прогон медленнее, чем 1-й, а 4-й медленнее, чем 3-й.
Может ли причиной этого отсутствие поддержки TRIM в ZFS-on-Linux - https://github.com/zfsonlinux/zfs/pull/8255 ?
Вместо отсутствующей поддержки TRIM (дефицита производительности которой часто можно избежать, просто оставив ~ 10% неразмеченного пространства в конце диска), вас, вероятно, поражает поведение ZFS CoW.
По сути, при работе с пустым набором данных вы можете писать, не требуя чтения / изменения / записи, потому что, ну, вы еще не много написали. Когда вы действительно переписываете данные (как в следующих тестах), вы будете постепенно увеличивать число операций чтения / изменения / записи, что приведет к усилению как чтения, так и записи (и снижению производительности).
Чтобы проверить, так ли это, просто используйте zpool iostat для записи общего числа операций чтения / записи при первых трех запусках: если вы видите, что второй и третий запускают команду на увеличенное количество переданных байтов, у вас есть подтверждение того, что написано выше.