Я обратился к одному мудрому человеку, предоставил доступ к серверу, вот его ответ
1. Во время "тормозов" можно нажимать Ctrl-T, чтобы узнать состояние задумавшегося процесса. У меня получилось поймать такой момент и состояние процесса было [vnread] - тормоза касаются дисковой подсистемы.
2. На корневой файловой системе не включены софтапдейты, это плохо. Нужно включить, не журналируемые. К сожалению, для корневой fs это можно сделать только из single user mode, причём после включения softupdates нельзя выходить напрямую в multiuser (изменения будут забыты), только через reboot.
3. Ядерная подсистема dirhash, ускоряющая доступ к большим каталогам, уперлась в лимит памяти:
$ sysctl vfs.ufs | grep mem:
vfs.ufs.dirhash_mem: 12894496
vfs.ufs.dirhash_maxmem: 13414400
Нужно удвоить лимит vfs.ufs.dirhash_maxmem и наблюдать затем за ростом vfs.ufs.dirhash_mem, если опять приблизится к лимиту - удвоить лимит снова и т.д.
4. systat -vm 3 показывает, что диски ada0 и ada1 сильно загружены (процент загрузки %busy близок к 100) множеством мелких запросов, значение KB/t (килобайт на транзакцию) очень мало и это убивает производительность дисковой подсистемы - современные диски очень плохо переносят много мелких запросов. Я сам не работал со страйпами, возможно они имеют ту же проблему что и RAID3, разбивая запросы к массиву у на несколько более мелких к индивидуальным дискам.
Против этой проблемы нужно применять geom_cache, который при получении запроса меньше заданного предела (имеет смысл выставлять предел в 128K) читает с диска блоками указанного предела и кеширует "лишние" данные, при следующих запросах возвращая результат из кеша и храня в памяти часто запрашиваемые дисковые блоки, как и любой кеш. Размер кеша выставляется при разметке gcache и ограничен только размером ядерной памяти. Это в разы улучшает работу дисковой подсистемы и, в том числе, увеличивает скорость чтения с дисков (MB/s в выводе systat), а сейчас она очень низка из-за малой величины запросов. На запись gcache полностью прозрачен, ничего не кеширует при записи.
То есть, нужно поверх массива gstripe создать один gcache, на нём разделы и монтировать уже эти разделы, чтобы всё чтение по пути к массиву проходило через gcache, который станет читать с массива крупными блоками по 128K и даже если gstripe разбивает запросы напополам, всё равно каждому диску достанется крупный запрос в 64K и производительность не пострадает.
Размер кеша у gcache указывается в блоках, а не в байтах.
На фоне всех указанных проблем только усугубляют состояние каталоги с очень большим количеством файлов на одном уровне (есть несколько каталогов)
Линейный поиск в них медленный и неэффективный. Система автоматически хеширует крупные каталоги, делая доступ к ним быстрыми, но только если не упирается в лимит памяти для dirhash, который я упоминал в прошлом сообщении. По возможности нужно реструктуризовать приложения так, чтобы они не хранили все файлы на одном уровне, либо если в этих каталогах быстро устаревающие данные типа короткоживущих файлов состояний php-сессий, организовать оперативную очистку устаревших файлов, чтобы они не накапливались в таком количестве. Ну, или на крайний случай, резко увеличивать лимит на dirhash и надеяться на эффективность системного хеширования поиска - об этом уже писал.
Реально я ему очень признателен за то что он нашел время и попытался диагностировать мою проблему.
Спасибо тебе dadv
