Tomcat, Apache, настройка MySQL
Я в настоящее время использую инфраструктуру AWS для хостинга моего приложения мобильного Интернета. Я использую веб-сервер Apache, mod_jk для передачи запросов Tomcat, который далее общается с MySQL DB с помощью пула соединения. Из недавно сервера отвечал медленно. Одной из причины является запрос (LocationUpdate), который поражен всеми пользователями, имеющими приложение случайным образом в 15-минутном интервале. То, которому я верю, является причиной замедления сервера. И другой, у нас есть многие пользователи также. Я задавался вопросом, как Загрузить Баланс это.
- Я не уверен, если его Apache, кто не может обработать эти много веб-запросов.
- Или Tomcat, который не может обработать их.
Так не уверенный, как я должен обработать его. Которые конфигурируют настройки для подтверждения. Я искал в Интернете, все же не было уверено, как понять это. Я должен увеличить Размер "кучи" Tomcat?
Прежде всего, вам нужно пересмотреть, действительно ли вашему приложению нужно «звонить домой» каждые 15 минут! Это помещает burdon не только на ваш сервер, но и в мобильную сеть, на телефоны людей и на их счета за передачу данных. В частности, если это обновление местоположения, приложение может быть запрограммировано так, чтобы не отправлять обновление местоположения, если изменение координат GPS по сравнению с последним переданным обновлением небольшое.
Во-вторых, вы должны отладить, что движет увеличить нагрузку на ваш веб-сервер. Используйте вверху , чтобы отобразить сведения о загрузке. Строка, представляющая особый интерес, выглядит так:
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) имеют высокую загрузку процессора. Затем оптимизируйте свое веб-приложение, чтобы снизить нагрузку на процессор. Если это не поможет, добавьте на сервер больше ядер процессора.
И последнее, но не менее важное: проверьте свою память с помощью бесплатно . Если используется большой процент вашей памяти или используется своп больше нескольких килобайт, добавьте больше памяти.