На счет размера этого файла не думаю что есть смысл на него как то опираться, как никак он все таки промежуточный, и главное чтобы записи из него успевали попадать в сами базы данных.
Его размером управлять нельзя это верно.
Но если есть большой объем записи в базу данных, то лучше расположить его на отдельном диске, так же как и файлы журналов. При высокой нагрузке по записи, все файлы в которые идет запись должны быть максимально распределены. И имееется ввиду не просто другой диск, а должен быть и другой контроллер. Таким образом загрузка одного диска не будет влиять на другой. Но в то же время стоит беспокоится и о хорошей доступности WIJ файла. Например, в нормальной высоконагруженной конфигурации, у вас должна быть дисковая полка подключенная по оптике к серверу в несколько контроллеров. На этой полке допустимо хранить файлы баз данных, но не стоит хранить WIJ файл, который лучше расположить на SSD диске на самом сервере и конечно в RAID. Выбор RAID тоже очень важная задача, хотя для хранения WIJ достаточно и простого зеркала из двух дисков, Но если дисков несколько, то тут важно не ошибится. У нас как то возникли проблемы с RAID5, и RAID наш благополучно умер, когда решил что вышло два диска подряд. Но данные спасли к счастью.

На что еще стоит обратить внимание, так это на то как быстро и как происходит реальная запись. Наблюдать это можно через mgtstat. Там есть такие показатели, как фаза WriteDaemon (WDphase), нужно следить чтобы WriteDaemon не был слишком долго в 8 фазе, это фактическая запись данных в базы данных. Фаза 5 это накопление WIJ. В нагруженных системах обычно только эти фазы, если система простаивает то фаза 0.
Wijwri - Показатель того сколько сейчас данных в WIJ
WDQsz - очередь WriteDaemon
PhyWrs - Собственно фактическая физическая запись в базу.

Но есть еще отличия, с которыми я если честно пока не сталкивался. На Windows может работать только один WriteDaemon, на Linux насколько я знаю из может быть больше, но как это можно менять я не знаю. Не было пока необходимости.

mgstat кстати полезен не только для мониторинга проблем с записью, но и в целом проблем с производительностью самого приложения. Блокировки, Эффективность использования кеша, буферов на ECP и т.д.

Наверно потому, что не просто описать как следить за всеми. Обычно за этими метриками начинают следить, когда возникают проблемы, падения сервера либо просто проблемы с производительностью по разным причинам, от обычного роста нагрузки или при внешних факторах (железо, ос).

Дело в том что при разных проблемах стратегии совершенно разные, и сводятся они в анализе многих показателей сразу и за определенный интервал, чтобы увидеть цифры в движении. Для этого они обычно просят запускать pButtons. Но если посмотреть на статьи на DC, то можно понять что даже разные сотрудники теподдержки пользуются своими вариантами анализа этих логов, и они выкладывают, то как они это делают.
InterSystems Data Platforms and performance – Part 2

Visualizing the data jungle -- Part I. Let's make a graph
И не только InterSystems
GUI на Grafana для mgstat — утилиты мониторинга системы на InterSystems Caché, Ensemble или HealthShare