|
В качестве небольшого охотничего рассказа: Меня однажды позвали тьюнить производительность к клиенту. При этом у клиента даже на простых операциях (типа разноски тупого журнала платежей или журнала отборочных накладных по производственному заказу) утилизация AOS взлетала до 80-90%. Меня это крайне удивило, поскольку вообще это был первый случай в моей практике, когда узким местом был AOS, а не SQL Server.
Вскрытие показало, что партнер поставил Entire Table Cache на таблицу с 120-130 тысячами записей и при этом обновляемую раз 5 в секунду. В результате - два AOS и один батч сервер в замкнутом цикле перечитывали эту злостастную таблицу. При этом как только один цикл перечитывания заканчивался, тут же начинался второй (поскольку кто-то уже успел ее обновить во время перечитывания).
Надо сказать - что я эту ошибку диагностировал скорее по счастливой случайности, чем в результате планомерных действий. На SQL Server это перечитывание выглядело как Fetch Cursor - было тяжело понять что именно происходит и не часть ли это нормальной разноски. А обычная трассировка AOS никакой полезной диагностики вообще не приносила.
Поэтому я НИКОГДА не использую этот метод кэширования. Выигрыш по сравнению с FoundAndEmpty - копеечный, а риски - нехилые.
|