LINUX.ORG.RU
ФорумAdmin

mysql высокая нагрузка на проц

 ,


0

1

сервак 4 ядра и 8 гб озу. сайт nginx+apache+php+mysql. при простое нагрузки нету. когда создаю 50 человек онлайн начинается большая нагрузка

скрин 1 https://ibb.co/0hGSXYJ

вот вывод mytop https://ibb.co/PWw5gQp

медленных запросов нету

вот конфиг mysql

 cat /etc/mysql/my.cnf
[client]
port=3306
socket=/var/run/mysqld/mysqld.sock

[mysqld_safe]
socket=/var/run/mysqld/mysqld.sock

[mysqld]
user=mysql
pid-file=/var/run/mysqld/mysqld.pid
socket=/var/run/mysqld/mysqld.sock
port=3306
basedir=/usr
datadir=/var/lib/mysql
tmpdir=/dev/shm
lc-messages-dir=/usr/share/mysql
log_error=/var/log/mysql/error.log

symbolic-links=0

#skip-external-locking
skip-name-resolve
skip-networking
key_buffer_size = 2M
max_allowed_packet = 200M
table_open_cache = 20000
table_definition_cache = 20000
open_files_limit = 40000
#sort_buffer_size = 1M
#read_buffer_size = 1M
#read_rnd_buffer_size = 4M
#myisam_sort_buffer_size = 64M
join_buffer_size = 5M
query_cache_limit = 1M
query_cache_size  = 8M
query_cache_type = 1

tmp_table_size = 256M
max_heap_table_size = 256M

#innodb_use_native_aio = 0
innodb_file_per_table

thread_cache_size = 250
max_connections = 250
#max_user_connections=10
wait_timeout=60
interactive_timeout=60
#long_query_time=5

innodb_buffer_pool_size = 3G
innodb_log_file_size = 384M
innodb_buffer_pool_instances = 3
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 128M

#innodb_buffer_pool_chunk_size = 128M

!includedir /etc/mysql/conf.d/

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
#log_queries_not_using_indexes=ON

#general_log = on
#general_log_file=/var/log/mysql/mysql-general.log

судя по нагрузке апач ждет когда mysql отработает запрос, а mysql не успевает? но почему? не думаю что конфиг так сильно вляет. или сервак физически не тянет 50 юзеров и нужен мощнее?

mysqltuner запускал и изменения вносил, после этого ничего умного не предлагает

скрин 1

Мускул грузит на 30%, остальное апач (пых), не сказал бы, что проблема явно в мускуле. Вполне возможно, что все настроено ок, просто сервер слабоват. Еще вариант, что проблемы нет вовсе, просто у вас тест такой.

когда создаю 50 человек онлайн

Вот что конкретно вы делаете?

судя по нагрузке апач ждет когда mysql отработает запрос, а mysql не успевает?

Нет, в общем-то.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от goingUp

изначально этот сайт был на другом сервере,я его перенес и решил проверить как новый сервер будет держать нагрузку.

limpopo44
() автор топика
Ответ на: комментарий от limpopo44

И чем вы это проверяете? Может быть, что утилита для нагрузочного тестирования просто отправляет запросы друг за другом в 50 потоков (и для этого случая 100% загрузка CPU норма), а вы думаете, что она эмулирует 50 пользователей.

goingUp ★★★★★
()
Ответ на: комментарий от iliyap

каким инструментом лучше проверять нагрузку?

limpopo44
() автор топика

Интересно как получается, а почему apache у тебя от двух пользователей запущен сразу - admin и www-data? Или ты из секты переименования root?

Dimez ★★★★★
()
Ответ на: комментарий от limpopo44

Не хочу расстраивать, но vestacp давно сдохла. Бери хотя бы hestia (тоже параша, но хотя бы поддерживается относительно)

anonymous
()
Ответ на: комментарий от anonymous

Ого, как говорится вспомнишь говно, оно и всплывёт.

Vesta is back under active development as of 25 February 2024. We are commited to open source, and will engage with the community to identify the new roadmap for Vesta. Stay tuned!

Интересно.

anonymous
()
Ответ на: комментарий от julixs

Я имел ввиду что хестия - форк Весты (внезапно ожившей), который видимо запилили из-за отсутствия активности в разработке весты. Про Брейни ничего не знаю, хотя слышал мельком.

Как по мне, они все не нужны, но если есть спрос то чому бы и нет. Какая разница на чем крутить джумлы и вордпрессы без посетителей.

anonymous
()

Судя по статусу R у процессов апача они у тебя что-то делают на оставшиеся от мускуля 360% CPU. Может https-хэндшейки обрабатывает, может пыхокод молотит

cobold ★★★★★
()
Ответ на: комментарий от cobold

Кстати, проиграл с тега «хайлоад». Там наверно ВордПресс стоит которого долбят в xmlrpc и wp-login.

anonymous
()
Ответ на: комментарий от anonymous

Брейни по первой кажется перегруженной, но мне зашла. ISPmanager еще не плоха.

julixs ★★★
()
Ответ на: комментарий от anonymous
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 1108500 696772 1611464    0    0   126    96   22   21  5  1 94  0  0```
limpopo44
() автор топика
Ответ на: комментарий от cobold

Ну шо поделать, с виртуалкой на 4 виртуальных ядра и 8 Гб памяти и 50 rps хайлоад ну если на пыхе писать и в говноапаче крутить, то да, хайлоад.

у нас тестовый стенд с 2 ядрами и 3 ГБ памяти, держит 1000+ rps на чтение из базы (postgres, nginx, lua)

anonymous
()
Ответ на: комментарий от Dimez

уж не mpm itk ли используется в apache?

Раньше он создавал существенную нагрузку т.к. это fork() + seteuid() на каждый запрос.

vel ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.