TEHbI4 PhyWrs Physical writes to disk.
WIJwri Number of 256-KB blocks written to the WIJ.
Jrnwrts Number of blocks written to journals.
WDQsz Write Daemon Queue size (in blocks).PhyWrs - блоки БД, обычно 8K.
Jrnwrts - блоки журнала, размер буфера 64K. Могут писаться неполными.
WDQsz - в блоках БД.

Проблемы типа вашей, как справедливо заметил DAiMor, обычно связаны с низкой скоростью дисковой подсистемы. Собирать статистику надо с интервалом 1 сек, иначе она малопоказательна. Но даже из ваших (судя по всему довольно грубых) графиков видно, что демон записи (Write Daemon) пробуждается чаще, чем 1 раз в 80 сек. Это признак либо слишком маленького кэша данных, либо действительно медленного disk i/o. Вы можете попытаться улучшить ситуацию с журналом, разместив каталог журналов на физически отдельном (от баз данных) диске. С нагрузкой справится практически любой диск, можно даже SATA, т.к. последовательная запись до 100 iops проблемой обычно не является.

Но бывает, что тормоза демона журнала связаны с нестабильной работой дискового контроллера. Недавно было у клиента.

TEHbI4В нормальном состоянии как часто просыпается демон записи?
По тому событию, которое наступит раньше:
1) Кол-во "грязных" буферов приближается к порогу активации демона записи (WD). Порог активации можно посмотреть в Портале - статистика по диску и буферам. Где-то читал, что он составляет около 25% размера кэша данных, но это верно лишь на небольших кэшах. Когда кэш >= 2GB, порог = 25600 8K-буферов (200 MB), и с ростом кэша уже не растёт (информация по v.2012.2 и близких к ней). В 2010.1 было действительно 25% (сохранился еще экземпляр, где смог проверить ))). Почему ISC проделала такое изменение, тема отдельного разговора.
2) Прошло 80 с
3) Нет буферов для выполнения операции чтения из БД.

Если на теневом серваке не работают, то 3 - вряд ли. Поэтому сразу и подумал, что ваш случай - 1: маловат кэш данных.

TEHbI4Речь идет именно журналах, верно понял? Да и вообще Journal Daemon отвечает конкретно за журналы или и за WIJ тоже?JD отвечает за журналы. WD - за WIJ, запись в БД, синхронизацию с JD.

Вы не указали $zv, но предполагаю, что она <= 2012.2. Куда вам плыть?
- Можно повысить версию до 2014.1 (действуя консервативно))), тогда 10с паузы JD уйдут: вместо них будут только предупреждения. Настоящие паузы будут только при 30c молчании JD.
- Можно вынести журналы на отдельный диск (как уже писал).
- Можно уйти на более мощный сервер. Нагрузка, в общем-то, небольшая, если с ней проблемы даже на тени, то в роли основного такой сервер скорее всего не потянет.
- Можно заняться алгоритмикой. Вас не смущает результат статистики? Грубо усреднив и приведя к KB/s:
Обычно сколько пишется в WIJ, примерно столько же - и в БД, а у вас в WIJ - втрое больше! Т.е. каждую секунду одни и те же данные перезаписываются примерно трижды.
- Можно попробовать увеличить кэш данных, если позволяет свободная память сервера, тем самым подняв порог активации WD.
- Можно в св-вах тени ( System > Configuration > Shadow Server Settings > Edit Shadow Server) отключить "вторичное" журналирование:
Disable journaling of shadow updates: Yes
одновременно увеличив:
Days of old copied journals to keep
Пожалуй, это самое простое, но не решит проблему (возможно) нестабильной работы сервера и его потенциальной непригодности к роли основного.

Насчёт алгоритмики может и перебор: подобный эффект бывает, когда журналируются (и соответственно затеняются) временные глобалы. В CACHETEMP их.