akurasaokomradнужно иметь свободную память в соответствующем кэше, там где хотите создать такой пул
т.е. фактически у нас нет пока пула на 4К. а какие обычно "показания" к его созданию? гигантские бд? правильно ли я поняла, что пулы это некие конекторы через которые ходит объем данных в базу? соответственно чем пул больше тем больший объем информации может быть записан?
да, пока такого пула нет
показания, обычно, - это необходимость в нем
а это зависит от паттернов ввода/вывода
http://www.lcard.ru/~nail/sybase/perf/25206.htm
цитатаChoosing the Right Mix of I/O Sizes for a Cache
You can configure up to 4 pools in any data cache, but in most cases, caches for individual objects will perform best with only a 2K pool and a 16K pool. Caches for databases where the log is not bound to a separate cache should also have a 4K pool configured for syslogs if 4K log I/O size is configured for the database.
8K pools might sometimes provide better performance in a few cases:
There may be some applications with extremely heavy logging where an 8K log I/O size would perform better than 4K log I/O, but most performance testing has shown the 4K log I/O size to be optimal.
In cases where a 16K pool is not being used due to storage fragmentation or because many of the needed pages are already in a 2K pool, an 8K pool might perform better than a 16K pool. For example, if a single page from an extent is in the 2K pool, 7 2K I/Os would be needed to read the rest of the pages from the extent. With an 8K pool, 1 8K I/O (4 pages) and 3 2K I/Os could be used to read the 7 pages. However, if a 16K pool exists, and a large I/O is denied, SQL Server does not subsequently try each successively smaller pool, but immediately performs the 2K I/Os. You would only configure an 8K pool if a 16K pool was not effective in reducing I/O. You can transfer all of the space from the 8K pool to the 16K pool using sp_poolconfig.
в вашем случае, сисмон постоянно рекомендует увеличить user log cache size
сейчас он 2к
если увеличивать его до 4к, потребуется 4к пул для эффективности внесенных изменений
кроме того, одна из рекомендаций :
sysmon Tuning Recommendations for Data cache : default data cache
-------------------------------------
- Consider using 'relaxed LRU replacement policy'
for this cache.
сейчас он у вас "strict LRU", если мне не изменяет память
Небольшое итого:
У нас уже идет пятая страница переписки, много всяких параметров можно и стоит поправить.
Поэтому, в идеале составить список желаемых изменений конфигурации, разбить их по критичности и трудоемкости.
Далее, менять параметры по одному и мониторить поведение системы.
В противном случае, применив их все скопом можно потенциально получить нежелательное поведение системы. И тогда, трудно будет понять, что именно (изменение какого параметра) к этому привело, что именно откатывать обратно.
В общем, изменения должны быть сделаны поочередно, с фиксацией результата.
