У нас есть сервер VMWare ESXi 4.1, на котором размещено несколько гостевых систем Linux и Windows. Недавно к этому серверу был добавлен новый гость Linux, который, похоже, работает хорошо. Затем были установлены Tomcat и некоторые другие приложения на этом сервере, которые, похоже, заставили сервер работать очень медленно без каких-либо очевидных проблем с ресурсами.
К медленной производительности относятся:
И консоль VMWare, и команды мониторинга не сообщают о каких-либо проблемах с высокой загрузкой процессора или памяти, но что-то, очевидно, каким-то образом замедляет работу сервера.
Есть ли у кого-нибудь идеи, что может вызывать эту проблему и как ее можно решить?
Спасибо,
Том
редактировать
Что касается ваших вопросов, я просмотрел некоторые индикаторы производительности как на хосте, так и на гостевой виртуальной машине.
Сначала я попытался зарезервировать полный объем памяти (3 ГБ) для этой виртуальной машины - никакие другие машины на этом сервере не имеют резервирования памяти.
Скорость обмена и скорость обмена для хоста и гостя виртуальной машины теперь равны нулю.
Баллонная память на гостевой системе равна нулю, а на хосте - 3,5 ГБ (общая память на хосте составляет 12 ГБ)
Ставка свопа для гостя также равна нулю.
Размер свопа, используемого хостом, составляет в среднем 200 МБ.
Скорость сжатия и декомпрессии для хоста и гостя равна нулю.
Прерывания команды для хоста равны нулю.
Задержка чтения очень низкая - максимум 10 мс, в среднем 0,8 мс.
Задержка записи выше - несколько скачков до 170 мс, но в основном около 25 мс - это плохо?
Задержка команды очереди равна нулю.
Задержка чтения с физического диска в среднем составляет 5 мс, но часто 10 мс.
Задержка записи на физический диск в среднем составляет 15 мс, но часто составляет 20 мс.
Надеюсь, это поможет - дайте мне знать, если вам понадобится дополнительная информация.
Это случилось и с нами на сервере Debian Lenny (5.0), в основном проблема времени входа в систему SSH, после установки Tomcat. После просмотра множества комментариев о разрешении DNS мы обнаружили, что нашу систему тормозил Avahi-Daemon, а не Tomcat.
Выполнение «apt-get purge avahi-daemon» решило задержку входа в систему ssh.
Здесь двойная виртуализация. У вас есть гостевая операционная система Java, работающая внутри другого гостя (LINUX) на хосте виртуализации. Все ваши вызовы из Java должны быть дважды переведены, прежде чем они попадут в реальные аппаратные ресурсы. Это рецепт более медленной, чем ожидалось, производительности по сравнению с родной в большинстве ситуаций.
Для гостевых операционных систем, таких как Java и решения для баз данных, типично иметь свои собственные естественные уровни объединения, чтобы иметь возможность консолидировать несколько экземпляров на одном аппаратном обеспечении, тем самым достигая такой же экономии затрат, как это обычно бывает в случае преобразования и всего размещать операционную систему в гостевой системе в рамках решения виртуализации. Основное преимущество использования встроенного механизма консолидации заключается в том, что вы избегаете добавления еще одного уровня арбитража на пути к фактическому аппаратному ресурсу, используемому гостевой операционной системой (Java). Иногда гипервизор будет вашим другом при предоставлении доступа к ресурсам, во многих случаях - нет.
Рассматривали ли вы возможность вырезать один уровень арбитража для доступа к оборудованию и посмотреть на более родной экземпляр VM tomcat, такой как сервер VMWARE tc, http://www.vmware.com/products/vfabric-tcserver/ или даже экземпляр ОС Java, такой как JNODE или SANOS?
Приведенные вами значения задержки диска не очень низкие, они довольно высокие. Задержка диска в 10 мс или более сделает интерактивное использование очень медленным. Взгляните на свою систему хранения и посмотрите, не превышена ли ваша подписка на количество операций ввода-вывода в секунду.
http://www.techrepublic.com/blog/datacenter/calculate-iops-in-a-storage-array/2182
Java имеет тенденцию сбивать с толку системы управления памятью VMWare, поскольку добавляет еще один уровень управления памятью.
Ссылка на статью в базе знаний приведена ниже. Но ключевым является размер зарезервированной памяти виртуальной машины (а не только размера памяти виртуальной машины) так, чтобы он был> = памяти Java (tomcat).