У меня есть сервер Linux (RHEL 5.8) с Java 7 и Tomcat 7.
Производительность низкая, и я почти уверен, что это медленные запросы к БД.
У нас сейчас 2 ядра, и средняя загрузка никогда не превышает 1,5, использование второго ядра часто составляет 0%. Они хотят попробовать добавить ядро, чтобы посмотреть, поможет ли это. Думаю, не будет. Обычно я добавляю еще один, только если вижу, что все ядра по крайней мере на какое-то время загружены до максимума.
Что вы думаете об этом? Когда вы говорите, что пора добавить больше ядер?
Больше информации БД находится на другом компьютере, управляемом администратором баз данных. Я системный администратор Linux.
ЦП: 2 ядра Intel (R) Xeon (R) CPU X5675 @ 3,07 ГГц 16 ГБ ОЗУ с 2 ГБ подкачки 8 ГБ выделено для кучи, использование кучи обычно менее 4 ГБ, пики составляют около 6 ГБ 120%
Ваша производительность может не иметь ничего общего с подсчетом ядер. У вас могут быть ограничения ввода-вывода или просто не хватает оперативной памяти в системе.
Каковы спецификации основного системного оборудования? Например. Модель процессора, тактовая частота, объем оперативной памяти.
Низкая производительность по сравнению с другим показателем? Твои ожидания? Спектакль всегда был плохим?
В общем, я смотрю на загрузку системы как на способ определить, достаточно ли количества ядер. Похоже, он находится на правильном уровне в вашей ситуации.
Производительность низкая, и я почти уверен, что это медленные запросы к БД.
Если вы уверены, что проблема в этом, оптимизировали ли вы установку MySQL или MSSQL? Простая установка программного обеспечения без настройки производительности не будет решена путем простого увеличения ресурсов.
Я рекомендую использовать Скрипт настройки MySQL для начинающих находится здесь. Очень прост в использовании, и рекомендации очень точны.
В зависимости от вашей установки вам может потребоваться научиться настраивать производительность вручную - это означает, что вы научитесь интерпретировать вывод MySQL самостоятельно и действовать в соответствии с ним, - но этот сценарий работает достаточно хорошо для 95% установок, на которых я когда-либо их использовал. Остальные 5% - это идиосинкразические настройки базы данных, требующие особого внимания. Я очень рекомендую уроки вроде этот в блоге о производительности MySQL.
Ограничения ввода-вывода наиболее вероятны.
SSD?
Перед добавлением дополнительных ядер было бы неплохо посмотреть, какие ресурсы фактически используются - например, если система привязана к вводу-выводу, добавление дополнительных ядер выбрасывает деньги, но обновление ваших дисков или ОЗУ, вероятно, решит проблему. . Попробуйте запустить vmstat (например, «vmstat 2») и проконтролировать io, память и процессор, чтобы получить представление о том, что происходит.
Поскольку вы находитесь в виртуализированной среде, добавление / удаление ЦП и памяти настолько простое, что практически невозможно. Так что просто сделай это. Затем, когда повышения производительности не наблюдается, вы указываете на отчеты о профилировании приложений и говорите: «Я же вам сказал».
При определении того, когда добавлять ядра к виртуальной машине, можно использовать несколько показателей. Использование ядра, как вы упомянули, является одним из наиболее очевидных показателей. Другие включают фактическую производительность ядра и возможность многопоточности приложений.
ЦП может быть узким местом производительности, даже если загрузка не превышает 10%. Обычно это происходит, когда ваш процессор просто медленный (1 ГГц против 2,5 ГГц), и вы хотите обновить базовое оборудование хоста. (Мой планшет с частотой 1,5 ГГц работает очень медленно, хотя загрузка ЦП никогда не превышает 10%. Это просто медленный ЦП!)
Есть еще много приложений, которые не являются многопоточными, поэтому независимо от того, сколько процессоров (ядер) вы им используете, они никогда не будут использовать более одного. Обычно в этом случае вам нужно изучить вопрос об обновлении вашего приложения, чтобы использовать преимущества нескольких процессоров, прежде чем добавлять новые к виртуальной машине. Кроме того, некоторые операционные системы также имеют ограничения (обычно основанные на лицензировании); например, Windows Server 2003 Standard поддерживает только 4 физических процессора, но не заботится о количестве ядер на процессор. Это может повлиять на добавление виртуальных ЦП или количество ядер на виртуальный ЦП к виртуальной машине.
Предполагая, что использование ресурсов моего хоста минимально, я бы добавил ядра к виртуальной машине, когда мои показатели производительности показывают, что средняя (средняя) загрузка ЦП превышает 50% в обычные рабочие часы. Это произвольное число, и в зависимости от ваших приложений и моделей использования вам может потребоваться больше ядер при средней загрузке процессора 25% или 75%, хотя к тому времени, когда ваше среднее значение достигнет 75%, вероятно, уже давно пора вносить какие-либо изменения. Вы захотите обратить внимание на постоянное использование по сравнению с пиками использования. Если ваш ЦП обычно находится на 5%, но поднимается до 100% каждые несколько минут, вы не хотите добавлять ядра, пока не определите причину скачков. К вашему сведению, vSphere имеет встроенные метрики производительности.
РЕДАКЦИЯ: Это, вероятно, наиболее подходит для приложения, которое имеет довольно постоянную нагрузку, например веб-сервера. Приложения с постоянной загрузкой, такие как сервер разработки, который компилирует код в течение 20 минут каждые 4 часа, будут совсем другими. В этом случае вы должны посмотреть на производительность приложения (компилятора) и пиковую загрузку ЦП при запуске этого приложения (компиляции). 100% ЦП во время всей операции компиляции, вероятно, выиграет от увеличения ЦП, если компилятор является многопоточным. Но тогда вы должны беспокоиться о том, что ваши разработчики рассердятся на вас за то, что вы время игры в половине.
Некоторые приложения, такие как MS SQL Server и MS Exchange, намеренно занимают ваши ресурсы (память является наиболее заметной), и это сделано намеренно, поэтому вам нужно знать, что ваши приложения должны делать. Вам необходимо сопоставить фактическую производительность приложения с использованием его ресурсов - если сервер SQL использует 100% ЦП и отвечает быстро, это отличается от сервера SQL, использующего 100% ЦП и медленно отвечающего.
Если производительность приложения низкая, но ваши показатели и тесты показывают, что ваш ЦП не является узким местом, тогда не беспокойтесь о добавлении ядер - хотя, если время простоя и ресурсы хоста не вызывают беспокойства, временно добавляйте ядра, чтобы доказать свою точку зрения. пользователям не нужно ничего, кроме 10 минут времени.
Также имейте в виду, что хороший гипервизор, такой как VMWare ESXi, допускает избыточное выделение ресурсов. Это означает, что вы можете выделить 4 виртуальных машины с 4 ядрами в каждой (всего 16 ядер), даже если у вашего хоста всего 8 ядер. Гипервизор динамически выделяет ресурсы хоста виртуальной машине, которая в них больше всего нуждается, поэтому с 3 простаивающими виртуальными машинами ваша 4-я виртуальная машина может использовать столько ресурсов вашего хоста, сколько вы можете выделить для нее. Уловка, на которую следует обратить внимание, - это лицензирование, поскольку некоторые приложения лицензируются. на ядро или на процессор а не для каждой машины или установки ОС.