Высокий трафик сервера mysql делает сайты очень медленными или неспособными загружаться
В последнее время у нас было много проблем с нашим сервером mysql из-за того, что веб-сайты были очень медленными или даже не могли их загрузить. Сервер - это выделенный сервер, на котором работает только наша база данных mysql. Я проводил некоторые тесты с использованием профилировщика (JetProfiler) и инструмента для стресс-тестирования (loadUI).
Если я использую loadUI для подключения с 50 одновременными подключениями к одному из наших веб-сайтов, который выполняет большой запрос, он уже не сможет загрузить веб-сайт. Одна из вещей, которая заставляет меня беспокоиться, заключается в том, что когда я смотрю на Jetprofile, он всегда показывает Treads_connected, равный 1,00, и кажется, что когда он достигает значения около 2,00, я не могу подключиться.
Три больших пика - это когда я запускаю тест с loadUI, первый - это 15 одновременных подключений, которые позволяют мне загружать веб-сайт, но очень медленно, второй - 40 одновременных подключений, которые уже сделали невозможной загрузку и третий был с подключением 100, что тоже больше не загружало.
Еще меня беспокоит то, что в JetProfiler говорится, что все используемые запросы - это полное сканирование таблицы, может быть, это проблема? Веб-сайт, который я запускаю в качестве теста, запускает 3 запроса: один для меню, которое выводит около 1000 строк, один для добавлений, содержащих около 560 строк, и один для получения сообщений, содержащих около 7000 строк (см. Снимок экрана ниже)
Я также следил за процессором сервера, и, похоже, там нет проблем, даже когда я делаю много подключений с loadui, процессор остается низким.
Кажется, я не могу понять, в чем основная причина того, что веб-сайты не могут загружаться при большом объеме трафика. Если у кого-то есть другие предложения по тестированию или что-то, что может вызвать проблему, сообщите мне.
Если при увеличении количества одновременных подключений происходит замедление, это может быть проблемой пула подключений. Если пул серверов / соединений настроен так, чтобы разрешать только определенное количество соединений (скажем, 5), то последующие соединения будут помещены в очередь до тех пор, пока в очереди не останется места. Кроме того, если попадание одной страницы приводит к запуску различных SQL-запросов, но каждый из них открывает новое соединение с MySQL (вместо повторного использования более раннего соединения), это может привести к созданию большого количества запросов на соединение.
То, как вы управляете пулом соединений, зависит от реализации (разные языки / библиотеки делают это по-разному), и есть золотая середина в том, сколько подключений к базе данных остаются открытыми. В таких системах, как Tomcat, сам Tomcat может быть настроен на открытие соединений с базой данных при ее запуске и доступ к ним для приложений / сервлетов по мере необходимости. Вам нужно будет профилировать свое приложение и его использование, чтобы увидеть, в чем состоит разумная золотая середина (поскольку при открытии ненужных соединений используется память).
В противном случае большинство языков сценариев, используемых для веб-материалов (например), имеют библиотеки баз данных, которые открывают соединение в начале страницы, а затем вы просто повторно используете эту ссылку для остальной части страницы. Стоит проверить, происходит ли это (хотя у вас может не быть полного контроля над кодом).
Я основываю это на проблемах времени, которые у меня были при работе с пулом соединений между веб-приложением Tomcat и собственной системой баз данных. Это может быть не актуально.
Несколько хороших картинок, но в вашем посте отсутствует много информации.
Какое максимальное количество подключений? Насколько велика база данных? Какой двигатель? Какой размер ключевого буфера? Сколько свободной памяти у СУБД?
полное сканирование таблицы, может быть, в этом проблема?
Может быть - информации недостаточно, чтобы сказать. Если запрос должен прочитать более одной десятой части данных, полное сканирование таблицы будет быстрее, чем поиск по индексу.
запросы, один для меню, которое выводит около 1000 строк
У вас есть меню на ваших веб-страницах с 1000 записями? Тогда большинство ваших проблем не в базе данных. Ваше приложение извлекает слишком много данных из базы данных. Если он затем отправляет эту информацию через Интернет, производительность будет ужасающий. Если он не отправляет все данные, которые он получает, то почему вы не выполняете фильтрацию в СУБД.
Каждая таблица имеет первичный индекс, вот и все.
Возможно, вам стоит подумать о согласовании вашей схемы с вашими запросами (т.е.добавить соответствующие индексы), но подумайте, что самая большая проблема у вас заключается в том, что вы получаете данные из СУБД, которые просто не используются.
OTOH означает ли вы, что когда вы анализируете запросы с помощью того же инструмента, что и на скриншоте, он сообщает вам, что обрабатывает тысячи строк? В этом случае исправление индексации будет иметь огромное значение.