В настоящее время я использую инфраструктуру AWS для размещения своего мобильного веб-приложения. Я использую веб-сервер Apache, mod_jk для передачи запросов в Tomcat, который далее взаимодействует с базой данных MySQL с использованием пула соединений. В последнее время сервер медленно отвечает. Одна из причин - это запрос (LocationUpdate), который выполняется всеми пользователями, имеющими приложение, случайным образом с 15-минутным интервалом. Я считаю, что это причина замедления работы сервера. Во-вторых, у нас тоже много пользователей. Мне было интересно, как это сбалансировать.
Так что не знаю, как мне с этим справиться. Какие настройки конфигурации подтверждать. Я искал в Интернете, но не знал, как это понять. Должен ли я увеличить размер кучи Tomcat?
Прежде всего, вам нужно пересмотреть, действительно ли вашему приложению нужно «звонить домой» каждые 15 минут! Это помещает burdon не только на ваш сервер, но и в мобильную сеть, на телефоны людей и на их счета за передачу данных. В частности, если это обновление местоположения, приложение может быть запрограммировано так, чтобы не отправлять обновление местоположения, если изменение координат GPS по сравнению с последним переданным обновлением небольшое.
Во-вторых, вам нужно отладить, что увеличивает нагрузку на ваш веб-сервер. Использовать top для отображения сведений о нагрузке. Особенно интересная строка выглядит так:
Cpu(s): 3.0%us, 6.0%sy, 1.6%ni, 85.9%id, 0.4%wa, 0.0%hi, 3.0%si, 0.0%st
Это от слабо загруженного сервера, который простаивает на 86%, так что в моем примере все нормально. В вашем случае это может выглядеть так:
Cpu(s): 3.0%us, 6.0%sy, 1.6%ni, 4.9%id, 81.4%wa, 0.0%hi, 3.0%si, 0.0%st
Чрезмерное "ожидание" означает, что ваши задания ждут, пока диск закончит чтение или запись данных. Если у вас возникла эта проблема, попробуйте уменьшить количество ненужных операций записи на диск (Google для noatime чтобы узнать об этом больше) и попробуйте снизить уровень безопасности записи в вашей базе данных, где это безопасно. Например, если обновление местоположения не записывается на диск должным образом в случае сбоя питания, последствия для вашей службы, вероятно, минимальны, поскольку в то время, когда это питание восстанавливается после ремонта неисправного компонента, местоположения в любом случае будут устаревшими . С другой стороны, если новые пользователи регистрируются, вы хотите, чтобы эти записи в основные данные учетной записи были синхронными, чтобы вы не потеряли учетные записи из-за сбоя питания или сервера.
Если даже после этих изменений время ожидания велико, подумайте о более быстрых дисках: RAID 1 с двумя или даже тремя дисками или SSD, прежде чем даже думать о балансировке нагрузки.
Если ваша линия нагрузки выглядит следующим образом:
Cpu(s): 43.0%us, 42.0%sy, 1.6%ni, 4.9%id, 5.4%wa, 0.0%hi, 3.0%si, 0.0%st
когда почти все процессорное время тратится в пользовательском режиме (нас) и системном режиме (нас), ваш процессор перегружается. Проверьте строки под заголовком в верхнем выводе, чтобы узнать, какие службы (например, apache2, tomcat, MySQL) имеют высокую загрузку процессора. Затем оптимизируйте свое веб-приложение, чтобы снизить нагрузку на процессор. Если это не поможет, добавьте на сервер больше ядер процессора.
И последнее, но не менее важное: проверьте свою память с помощью free. Если используется большой процент вашей памяти или своп используется более нескольких килобайт, добавьте больше памяти.