- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте!
У меня немножко нестандартная проблема.
Имеется сервер с большим онлайном (8к-9к человек, судя по гугл.аналитике). И когда цифра переваливает за 6500 онлайна, до mysql становится сложно достучаться, а конкретнее рандомно валится вот с такой фигней:
В качестве сервера - percona, и она сама по себе чувствует себя нормально, да и сервер ЛА вполне милый - от 0 до 4.
Исходя из этого, у меня большие подозрения на конфигурацию именно системы. Вчера проштудировал параметры ядра, в частности поднял количество тредов, количество открытых сокетов, уменьшил время ожидания соединения tcp/ip, и поднял спокойный онлайн до 6500 человек (раньше такая ошибка вываливаться начинала уже при 3500).
Дальше не знаю уже что делать. Поэтому и прошу помощи у вас.
Предположение, что именно ему сокетов и не хватает.
Сейчас онлайн 2500, при 7500 цифры немного другие(примерно такие, пишу по памяти):
До конфига my.cnf руки пока не дошли, к сожалению, поэтому показываю то, что досталось.
Напоминаю, что
Логи mysql, syslog, messages молчат как рыбы :-(
Не в пользу моей теории с сокетами говорит то, что выпадает только mysql, остальные приложения работают штатно.
Жду от вас предложений, буду рад любым!
Для интереса не пробовали localhost менять на 127.0.0.1 в настройках? Т.е. уходить с unix сокета на TCP.
запустите тюнер и покажите его вывод.
желательно чтобы mysql работал подольше перед запуском тюнера.
в вашем конфиге, я бы сразу поставил значительно больше кеш запросов
query_cache_size = 16M // хотя бы 128 - 256M
под вопросом:
key_buffer = 1024M // у вас индексы занимают 1гиг?..
tmp_table_size = 256M
max_heap_table_size = 1024M // если не ошибаюсь, то жто значение не может быть больше чем tmp_table_size (лень смотреть доку)
по диагностике тюнера многое станет понятно. возможно банально, в пиках не хватает памяти.
Итак, перевесил на 127.0.0.1.
Поднастроил сам mysql.
Еще немного пошаманил над самим сервером.
В данный момент пока не вылетает, но и народу на сайте столько нет. Следующий наплыв ожидается в воскресенье, тогда и отпишусь.
Скорее всего упирается в max_connections.
Через TCP будет работать медленней, чем через unix socket. Да оно тут и ни при чём скорее всего.
max_connections
а фак.... опередели. короче - key_buffer не нужен вам такой, query_cache побольше сделайте, только не надо максимализма, и ставить туда сразу 700М
;12151944']Скорее всего упирается в max_connections.
Через TCP будет работать медленней, чем через unix socket. Да оно тут и ни при чём скорее всего.
Это в теории, на практике - ничуть не медленней. Я, конечно, не замерял, но по ощущениям - ничего не поменялась, может быть какие-нибудь микросекунды. Почему не поможет?
Кто-то мне сказал, что мол это только сам сервер слушает порт, а общается он все равно с базами через сокет, это так? (Я еще не гуглил такую информацию)
max_connections
а фак.... опередели. короче - key_buffer не нужен вам такой, query_cache побольше сделайте, только не надо максимализма, и ставить туда сразу 700М
Я это знаю :-) может быть не супер тонкости mysql, но все первичные советы по настройке уже чуть ли не наизусть помню :-)
А вот max_connections
Да и я все же подозреваю, что не в mysql дело, именно в системе, в ядре, может быть еще где-то :-(
Highes connection usage у вас конечно высоковат ... Вы используете pconnect? wait_timeout не пробовали поменьше делать? Много ли sleep процессов висит?
Highes connection usage у вас конечно высоковат ... Вы используете pconnect? wait_timeout не пробовали поменьше делать? Много ли sleep процессов висит?
pconnect нет, обычный mysql_connect
wait_timeout выставил сейчас в 15000
sleep'ов штук 7-12, не больше
Как уже рекомендовали выше, запустите mysqltuner: https://github.com/major/MySQLTuner-perl/blob/master/mysqltuner.pl и покажите вывод. Много полезного можно будет узнать.
Итак, после настройки ядра и сервера mysql - БД выдержала.
Вылезли уже другие ошибки, но это тема отдельной истории, туда моя оптимизация еще не дошла.
Если в кратце подвести итог:
- mysql был поднастроен через приводившийся в этой теме mysqltuner.pl и еще в закромах у меня есть tuning-primer.sh.
- в самом ядре был прокачан стек tcp/ip, количество сокетов, выделяемой памяти и работа со swap'ом
- были поднастроены лимиты для пользователя mysql в /etc/security/limits.conf
Возможно что-то еще по мелочи, я точно не помню.