Мой веб-сайт и сервер огромны и тяжелы, на моем сервере 8 ГБ ОЗУ и 6 ядер процессора.
Я получил письмо от моей команды хостинга относительно загрузки базы данных mysql,
Сейчас мой сайт работает очень медленно, а полученное письмо содержит файл журнала.
root@server [~]# mysqladmin pr
+-------+------------------+-----------+--------------+---------+------+--------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-------+------------------+-----------+--------------+---------+------+--------------+------------------------------------------------------------------------------------------------------+
| 17969 | leechprotect | localhost | leechprotect | Sleep | 103 | | |
| 18706 | database_user | localhost | database_name | Sleep | 25 | | |
| 18717 | database_user | localhost | database_name | Query | 19 | Sending data | SELECT DISTINCT SQL_CALC_FOUND_ROWS
se_users.user_id,
se_users.user_username,
se_users.us |
| 18737 | database_user | localhost | database_name | Query | 19 | Sending data | SELECT DISTINCT SQL_CALC_FOUND_ROWS
se_users.user_id,
se_users.user_username,
se_users.us |
| 18745 | database_user | localhost | database_name | Query | 20 | Sending data | SELECT DISTINCT SQL_CALC_FOUND_ROWS
se_users.user_id,
se_users.user_username,
se_users.us |
| 18752 | database_user | localhost | database_name | Query | 19 | executing | SELECT DISTINCT SQL_CALC_FOUND_ROWS
se_users.user_id,
se_users.user_username,
se_users.us |
| 18777 | database_user | localhost | database_name | Query | 17 | executing | SELECT DISTINCT SQL_CALC_FOUND_ROWS
se_users.user_id,
se_users.user_username,
se_users.us |
| 18815 | database_user | localhost | database_name | Query | 15 | Sending data | SELECT DISTINCT SQL_CALC_FOUND_ROWS
se_users.user_id,
se_users.user_username,
se_users.us |
| 18926 | database_user | localhost | database_name | Query | 2 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18951 | database_user | localhost | database_name | Sleep | 1 | | |
| 18952 | database_user | localhost | database_name | Query | 1 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18953 | database_user | localhost | database_name | Sleep | 1 | | |
| 18954 | database_user | localhost | database_name | Sleep | 1 | | |
| 18955 | database_user | localhost | database_name | Query | 3 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18958 | database_user | localhost | database_name | Sleep | 1 | | |
| 18960 | database_user | localhost | database_name | Query | 2 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18961 | database_user | localhost | database_name | Query | 2 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18962 | database_user | localhost | database_name | Query | 3 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18963 | database_user | localhost | database_name | Query | 3 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18964 | database_user | localhost | database_name | Query | 2 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18965 | database_user | localhost | database_name | Query | 1 | executing | SELECT DISTINCT SQL_CALC_FOUND_ROWS
se_users.user_id,
se_users.user_username,
se_users.us |
| 18967 | database_user | localhost | database_name | Sleep | 0 | | |
| 18968 | database_user | localhost | database_name | Query | 2 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18974 | database_user | localhost | database_name | Query | 2 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18978 | database_user | localhost | database_name | Query | 1 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18979 | database_user | localhost | database_name | Query | 1 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18980 | database_user | localhost | database_name | Query | 1 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18982 | database_user | localhost | database_name | Query | 1 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18983 | database_user | localhost | database_name | Sleep | 0 | | |
| 18984 | database_user | localhost | database_name | Query | 1 | executing | SELECT DISTINCT SQL_CALC_FOUND_ROWS
se_users.user_id,
se_users.user_username,
se_users.us |
| 18985 | database_user | localhost | database_name | Query | 1 | Sending data | SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1' |
| 18986 | database_user | localhost | database_name | Sleep | 0 | | |
| 18987 | database_user | localhost | database_name | Sleep | 0 | | |
| 18988 | database_user | localhost | database_name | Sleep | 0 | | |
| 18989 | database_user | localhost | database_name | Sleep | 0 | | |
| 18990 | root | localhost | | Query | 0 | | show processlist
Я не могу понять этот журнал, может ли кто-нибудь помочь мне в этом
Моя главная команда
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11050 mysql 15 0 1510m 272m 4080 S 629.0 7.0 675:31.90 mysqld
26990 database_user 16 0 130m 24m 6812 R 25.4 0.6 0:00.84 php
26989 database_user 16 0 155m 39m 7652 R 21.8 1.0 0:00.76 php
26988 database_user 16 0 154m 38m 7648 R 21.5 1.0 0:00.74 php
27011 database_user 16 0 0 0 0 R 18.8 0.0 0:00.57 php
26835 database_user 16 0 156m 40m 7632 R 17.5 1.0 0:00.69 php
26909 database_user 16 0 0 0 0 Z 16.5 0.0 0:00.68 php <defunct>
26977 database_user 16 0 0 0 0 Z 14.2 0.0 0:00.51 php <defunct>
26947 database_user 15 0 154m 37m 7632 R 12.9 1.0 0:00.58 php
26844 database_user 16 0 0 0 0 Z 11.2 0.0 0:00.59 php <defunct>
26956 database_user 15 0 154m 38m 7632 R 10.9 1.0 0:00.42 php
27005 database_user 16 0 146m 30m 7596 R 8.3 0.8 0:00.25 php
27058 database_user 16 0 139m 22m 7328 S 7.9 0.6 0:00.24 php
26878 database_user 16 0 0 0 0 Z 7.6 0.0 0:00.44 php <defunct>
27052 database_user 17 0 140m 23m 7292 R 7.6 0.6 0:00.23 php
27037 database_user 15 0 143m 26m 7320 S 7.3 0.7 0:00.22 php
26964 database_user 16 0 0 0 0 Z 6.9 0.0 0:00.29 php <defunct>
:)
Команда хостинга предоставила не журнал, а текущий запущенный процесс Mysql, полученный из mysqladmin pr (ocesslist).
И ваш список процессов Mysql показывает, что у вас есть несколько экземпляров в основном двух запросов:
ВЫБЕРИТЕ count (friend_id) AS total_friends FROM se_friends ГДЕ friend_status = '1'
ВЫБЕРИТЕ DISTINCT SQL_CALC_FOUND_ROWS se_users.user_id, se_users.user_username, se_users.us
Я не уверен, что они полные, но тогда вам следует оптимизировать свои запросы. например: - вы должны использовать count (*) вместо count (friend_id)
И разве у вас не включен кеш запросов? Если нет, вы должны включить это, так как это значительно улучшит производительность. Если вы это сделаете, вам следует проверить состояние кеша запросов, чтобы настроить его дальше, чтобы ваши наиболее часто используемые запросы оставались в кеше.
Согласно выводам системы, Mysql занимает более 600% ЦП, и похоже, что ваш сервер Mysql очень нуждается в некоторой настройке. Кстати, ваша верхняя интерпретация неверна, это не пользователь db (пользователь mysql), а пользователь системы.
А поскольку многие процессы PHP также потребляют нагрузку на сервер, ваш сервер в целом требует некоторой настройки. Сделайте это раньше, чем позже.
Чтобы оптимизировать Mysql, вы должны попытаться настроить следующие переменные:
Следующие переменные установят глобальные буферы
max_connections
max_user_connections
table_cache
key_buffer_size
query_cache_size
приведенные ниже переменные будут установлены для буферов потоков:
tmp_table_size max_heap_table_size
read_buffer_size sort_buffer_size
join_buffer_size
нижеприведенные переменные должны быть настроены, если вы используете InnoDB:
innodb_log_buffer_size
innodb_additional_mem_pool_size
innodb_buffer_pool_size
Есть много других переменных, на которые нужно обратить внимание. Однако, если вы настроите указанные выше переменные в соответствии с вашими требованиями, это существенно изменит производительность.
Однако не делайте этого, если вы действительно не понимаете, какое значение должно быть правильным для этих переменных. Так что изучите это, прежде чем приступать к настройке Mysql на рабочем сервере, поскольку это может иметь неприятные последствия, если вы не сделаете это должным образом.
Если у вас нет времени на обучение, приведите кого-нибудь, кто знает свою работу, чтобы ее выполнить.
Многие процессы в «Отправке данных» подразумевают, что либо что-то не так с обработкой ответов на логическом уровне, либо что многие запросы возвращают очень большие наборы результатов. Вы не упомянули, в чем реализован логический уровень.
Глядя на SQL, снова и снова возникает один и тот же SQL:
SELECT count(friend_id) AS total_friends FROM se_friends WHERE friend_status='1'
Я искренне надеюсь, что это усечено - и что в команде отсутствует более значимая и конкретная часть - иначе это вообще не имеет смысла. Вы должны увидеть больше из журнала медленных запросов.
Этот запрос возвращает только одну строку. Но для выполнения SQL и логики для извлечения данных требуется около 2 секунд (поскольку ни один из них не выполняется, это говорит о том, что запрос выполняется очень быстро, менее 0,1 секунды - большая часть времени занимает логическим уровнем). Хотя это может возникнуть из-за очень медленной сети между базой данных и логическим уровнем, здесь это не так (соединения с localhost). Это также может произойти, когда есть проблема с переключением контекста - сервер базы данных и клиент постоянно получают приоритет от какого-либо другого процесса. Но с 6 ядрами это должен быть очень агрессивный процесс.
Если вы можете заставить свой логический уровень извлекать данные раньше, это будет иметь огромное значение для нагрузки.
Пожалуйста, предоставьте более подробную информацию о выполняемом SQL, уровне логики и выводе 'top'
Глядя на столбец времени выше, кажется, что следующий оператор является самым медленным:
SELECT DISTINCT SQL_CALC_FOUND_ROWS se_users.user_id, se_users.user_username, se_users.us
Это занимает больше всего времени, и похоже, что это просто выделение всей таблицы, но я не могу сказать наверняка, потому что похоже, что остальная часть оператора была отключена ...
Чтобы изменить это, вы можете включить оператор WHERE, который ссылается на индексы, используя LIMIT команду или используйте ОБЪЯСНИТЕ команда для отладки вашего оператора.
Вы можете также изучить mysqltuner если у вас есть возможность / доступ для настройки БД. Если вы пытаетесь отладить загрузку своей базы данных MySQL, вывод top, вероятно, не имеет значения.