Исключительно тормозит дисковая система. Причем на
запись. Если включить perfmon на предмет помониторить жесткий диск можно
видеть, что какой то процесс (vmware) отчаянно пишет на диск. Raid 5
как известно более тормознутый на запись чем raid 1 и raid 10, а в особо
отличившихся случаях - даже медленее одиночного винта )
Что за железка, кстати, для рейда, сколько шпинделей в массиве? Какие
политики на кеш?
Причина в том, что при старте виртуалки на диске
создается файл равный по размеру оперативки и туда непрерыно идет запись
инфы из оперативки виртуальной памяти.
Проблема с производительностью в данной ситуации решается просто. В
конфигурационном файле нужно прописать следующие волшебные строки для
самой лучшей производительности. Да, еще, контроллер LSI BUS, файлы
дисков виртуальных машин фиксированные и тип диска - оптимизирован для
производительности.
первые два параметра - консолидация памяти.
MemTrimRate = «0» - запрещает выгружать из оперативки хоста память виртуальной машины во время простоя виртуалки (скажем выставлено у тебя 2048 для виртуалки, а потребляет она в реальности только 1024, при старте на хосте на эту вируталку будет выделено 2048, но по мере того как память не будет использоваться она будет … утекать)
sched.mem.pshare.enable = «FALSE» - запрещает совместное страничное пространство, предположим запущено у тебя две машины на которых запушены одинаковые процессы - в памяти хоста будет запущен один процесс используемый обоими вируталками
в принципе отвечают за отклик системы - можно даже и не ставить, если отклик системы не очень важен, через 1 секунду у тебя это произойдет или через 5
MemAllowAutoScaleDown = «FALSE» - запрещает выгружать память вирутальной машины из оперативки на винт даже в случае если у хоста не хватает оперативки на собственные нужды параметр применять оч аккуратно и только в случае большого колва оперативки на хосте у меня как то в тестах две машины передрались за оперативку - выставил больше чем на хосте в сумме с отменой конослидации памяти это привело к подвисанию хоста, хотя до этого работало нормально, общая сумма оперативки выделенных для вируталок была 1200 при физической 1024 )
mainMem.useNamedFile = «FALSE» - самый главный параметр для производительности дисковой системы. запрещает выгружать память виртуальной машины на диск, в штатном режиме при запуске в папке с вируальной машиной появляется файлик размером равной оперативки вируталки и содержимое памяти виртуальной машины непрерывно пишется в файл. вообще эта фигня придумана для того чтобы не потерять данные находящиеся в оперативки вирутальной машины при отключении питания на хосте, так что применять только в случае наличия упса.
Вообщем-то mainMem.useNamedFile = «FALSE» было бы достаточно, но я решил закинуть все параметры, все таки тонкие клиенты очень зависят от отклика системы, на кассовом сервер можно было и не делать отмену консолидации памяти, но оперативки до фига, так что нехай будет
Имхо стоит все же еще поменять raid 5 на raid 1 или raid 10
На железе 1 - Xeon 5472 (quad) + 8 gb + adaptec 2405 raid 1 sata (500 gb) у меня крутится 4 виртуалки - 2 контроллера домена (на одном дополнительно к DC - WSUS, на втором сервер symantec и DFS) сервер тонких клиентов на 10 пользователей и кассовый сервер с sql 2000 все прекрасно чувствует себя и отменно летает.
MemTrimRate = «0»
sched.mem.pshare.enable = «FALSE»
MemAllowAutoScaleDown = «FALSE»
mainMem.useNamedFile = «FALSE»
MemTrimRate = «0» - запрещает выгружать из оперативки хоста память виртуальной машины во время простоя виртуалки (скажем выставлено у тебя 2048 для виртуалки, а потребляет она в реальности только 1024, при старте на хосте на эту вируталку будет выделено 2048, но по мере того как память не будет использоваться она будет … утекать)
sched.mem.pshare.enable = «FALSE» - запрещает совместное страничное пространство, предположим запущено у тебя две машины на которых запушены одинаковые процессы - в памяти хоста будет запущен один процесс используемый обоими вируталками
в принципе отвечают за отклик системы - можно даже и не ставить, если отклик системы не очень важен, через 1 секунду у тебя это произойдет или через 5
MemAllowAutoScaleDown = «FALSE» - запрещает выгружать память вирутальной машины из оперативки на винт даже в случае если у хоста не хватает оперативки на собственные нужды параметр применять оч аккуратно и только в случае большого колва оперативки на хосте у меня как то в тестах две машины передрались за оперативку - выставил больше чем на хосте в сумме с отменой конослидации памяти это привело к подвисанию хоста, хотя до этого работало нормально, общая сумма оперативки выделенных для вируталок была 1200 при физической 1024 )
mainMem.useNamedFile = «FALSE» - самый главный параметр для производительности дисковой системы. запрещает выгружать память виртуальной машины на диск, в штатном режиме при запуске в папке с вируальной машиной появляется файлик размером равной оперативки вируталки и содержимое памяти виртуальной машины непрерывно пишется в файл. вообще эта фигня придумана для того чтобы не потерять данные находящиеся в оперативки вирутальной машины при отключении питания на хосте, так что применять только в случае наличия упса.
Вообщем-то mainMem.useNamedFile = «FALSE» было бы достаточно, но я решил закинуть все параметры, все таки тонкие клиенты очень зависят от отклика системы, на кассовом сервер можно было и не делать отмену консолидации памяти, но оперативки до фига, так что нехай будет
Имхо стоит все же еще поменять raid 5 на raid 1 или raid 10
На железе 1 - Xeon 5472 (quad) + 8 gb + adaptec 2405 raid 1 sata (500 gb) у меня крутится 4 виртуалки - 2 контроллера домена (на одном дополнительно к DC - WSUS, на втором сервер symantec и DFS) сервер тонких клиентов на 10 пользователей и кассовый сервер с sql 2000 все прекрасно чувствует себя и отменно летает.
Комментариев нет:
Отправить комментарий