если проблема с mysql
надо смотреть прежде всего в оптимизацию запросов и в смотреть в чем затык
ставится mytop
жмется S и зарежка 1 (секунда)
далее видно какие запросы проходят в базу и какова у них скорость выполнения
если запрос задерживается дольше 5-7сек - это проблема.
потом самое важное - где mysql хранит временные выборки? по-дефолту mysql выгружает на диск, что вообще не добавляет радости диску, ему еще статику отдавать с разных мест.
поэтому временный диск для кеша mysql правильные пацаны переносят в tmpfs, то есть на виртуальный диск, тем самым резко снижая нагрузку на жесткий диск
выглядит примерно так:
| Код: |
tmpfs 1.0G 97M 928M 10% /tmp/ramdisk
|
ну далее уже по-мелочи, вставляем в /etc/sysctl.conf:
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
vm.swappiness = 10
vm.vfs_cache_pressure = 50
vm.dirty_background_ratio = 50
vm.dirty_ratio = 80
net.ipv4.tcp_rmem = "4096 25165824 25165824"
net.core.rmem_max = "25165824"
net.core.rmem_default = "25165824"
net.ipv4.tcp_wmem = "4096 65536 25165824"
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syncookies = 1
net.core.somaxconn = 16384
fs.file-max = 1048576
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_tw_recycle = 1
и делаем sysctl -p
теперь самое важное:
если баз данных / таблиц в mysql много (у меня порядка 300 таблиц в БД), нужно править open_files_max (максимально количество открытых файлов), ибо может случится так, что mysql и тот же nginx упрется в лимит и алес капут.
и rlimits в /etc/limits не всегда помогают
проверяется так:
| Код: |
# ps ax |grep mysql
1115 ? Ssl 2090966:00 /usr/sbin/mysqld
# cat /proc/1115/limits
Limit Soft Limit Hard Limit Units
...
Max open files 1024000 1024000 files
|
вот эта строчка показывает максимально скоко процесс может открыть файлов.
так же проверятся для апача и nginx.
если стоит какая убунта/centos там может стоять systemd ебучий, который перекрывает /etc/limits/
и там нужно уже изъебываться нетрадиционно чтобы поправить лимиты (кому интересно - расскажу про извращения отдельно).
Итак лимиты поправлены, sysctl подкручен, что еще?
во-первых - МОЗГИИИИИ!!!
чем больше мозга, т.е. памяти на сервере, тем больше уйдет в файловый кеш.
вот у меня два бэкенда. процы у них одинаковые, в одном стоит обычный жесткий диск, во втором софтрайд на два диска.
Какой из серверов быстрее?
Ответ: первый, потому что у него 64гига моска, а у второго 32гига.
Первый закешировал в память все файлы mysql и часто отдаваемую статику с диска,
на втором сервере кеша на файлсистему особо не хватает и iotop показывает очень большую нагрузку на READ/WRITE, отчего сервер притормаживает
то есть первый сервер на load averages 30-40 живет себе нормально, второй уже загибается на LA 15+
во-вторых, собственно диск. база данных+статика на SSD это панацея от IO-нагрузки на диск, даже если памяти мало. Весьма спасает.
А если SSD raid10 - ваще песня, там летает все просто ахуенно.
У меня du -hs каталог/ где лежат полмилиона мелких файлов
считается за полминуты
полезные инструменты:
mytop - смотрим какие запросы долго исполняются в mysql
iotop - смотрим какой процесс жрет диск
htop - смотрим общую статистику нагрузки на сервер, включая по коркам и ядрам
trafshow - смотрим чо творится на сетевом интерфейсе
free -m
смотрим скоко памяти ушло под кеш и скоко свопа (своп больше 2-3гиг это ахтунг, надо срочно чото-то делать с оптимизацией)
