localhost
если проблема с 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гиг это ахтунг, надо срочно чото-то делать с оптимизацией)
NatalieX
Я думаю причина одна из двух (а возможно и обе):
1. Хост может перепродавать пропускную способность свича, к которому подключается Ваш сервер.
Например, если сервер подключается к 24-портовому свичу с 2х-гигабитными аплинками в WWW, то все клиенты, подключенные к этому свичу, конкурируют за доступ в Интернет. Если дело в этом, напрямую вам об этом конечно не скажут.
2. Сервер действительно необходимо оптимизировать.
Наша тех поддержка всегда помогает оценить ситуацию и предлагает варианты изменения конфига так, чтоб повысить производительность операционки и системы вцелом. Возможно проблема с SSD или HDD и нужно определить есть ли варианты апгрейда, поможет ли просто покупка большего количества драйвов, или необходимы более качественные SSD. Ну или же, как Вы сами предложили, поможет разделение работы на несколько серверов. Наши сисадмины специализируются на анализе и качественном решении подобных задач.
В любом случае - грамотный хост всегда поможет траблшутить и предложит варианты решения. Отмазка "у вас больше трафа и потому все плохо" - это очень печально. Если Вы готовы рассматривать "переезд" как решение проблемы - пишите в ПМ.