- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Так не используйте mysql для статистики - для этого есть мемкеш
А из него раз в час пакетным инсертом скидывайте в мискуль
Нравятся мне такие рекомендации.. неизвестно какой скрипт, неизвестно что пишет, и... неизвестно, какая квалификация у ТС. Возьми, перепиши всё нафиг.
Таблицы MyIsam.
2. Стату кешировать никак нельзя, т.к. каждый запрос заканчивается записью строки в таблицу БД и возвратом некоторых данных запрашивающему.
Таблицы с активной записью (а можно и все) в InnoDB перекинь.. после того, как поработает сутки-другие (после первой настройки можно и раньше - дефолтные "буфера" наверняка сразу проявят себя) - посмотри статистику по использованию. Можно скрипт какой-нибудь запустить (mysql_primer, например) - он "подскажет", какие настройки поменять.
slow_query_log включи (если не включен) - возможно, индексы потребуются для JOIN-ов.. или часть таблиц в память вынести.
Для грубой настройки вполне пойдёт. Более тонкий тюнинг - смотреть по обстановке.
О, вчера был выходной а сейчас сразу много! Всем спасибо за идеи.
Ну и смысл? Будет nginx всеми потоками ждать пока база ответит и не принимать новые запросы.
посмотрю что можно сделать
ну нет там того что можно кешировать. Запросы в БД все разные.
А из него раз в час пакетным инсертом скидывайте в мискуль
Это идея хорошая, но тогда возможны сбои в стиле что следующая запись должна ссылаться на предыдущую а та еще не добавлена потому она никуда не ссылается или ссылается не на ту... Тут надо алгоритм полностью менять будет.
Первое что я сегодня сделаю. Я выбирал MyISAM потому что судя по какому-то мануалу или статье он был более оптимален для моих задач. Проверю так ли это. Joinов там нет, основная работа с одной таблицей.
Нравятся мне такие рекомендации.. неизвестно какой скрипт, неизвестно что пишет, и... неизвестно, какая квалификация у ТС. Возьми, перепиши всё нафиг.
Пусть наймет фрилансера и тот ему перепишет.
Что посоветуете?
Я бы посоветовал начать с запросов которые "mysql не успевает отрабатывать"
Ну и смысл? Будет nginx всеми потоками ждать пока база ответит и не принимать новые запросы.
Смысл в том, что вы избавитесь от прожорливого апача. Но раз по вашему проблема в базе, ее и оптимизируйте. И только конфиги, но и структуру еще раз продумайте.
Пусть наймет фрилансера и тот ему перепишет.
Полагаю, если бы изначально было желание переписать скрипт, самостоятельно или силами фрилансера - ТС бы не обратился в раздел Администрирование.
Смысл в том, что вы избавитесь от прожорливого апача.
Nginx мордой на статический контент, Apache в бекенде, Mysql
siv1987, если статика отдаётся Nginx-ом (да ещё req limit настроен), замена apache на php-fpm не всегда даёт достаточно заметный эффект (в некоторых ситуациях он может быть и отрицательным)... Тонким "тюнингом" прокачать можно и то и другое... Холиварить не буду - при необходимости в нете можно найти бенчи (в т.ч. и от Andreyka) и рекомендации по настройке.. /естественно, задачу отдачи статики на Apache не вешаем./
Ещё можно xcache/APC/Eaccelerator поставить.. Для общей производительности плюсиком будет... конечно, после решения проблемы с базой.
Теперь я вообще ничего не понимаю. Была свободная память, апачи не размножались, база тормозила.
Все что сделал - перевел таблицу в InnoDB перед этим его включив в конфиге. Теперь запросы SELECT стали заметно медленнее работать (это без пика нагрузки).
В результате в пике проц сожран на 100%, памяти тоже нет и апачей не 10-11 как было а больше 15. Настройки вебсервера не менял. Где эти лишние апачи были при MyISAM?
siv1987, если статика отдаётся Nginx-ом (да ещё req limit настроен), замена apache на php-fpm не всегда даёт достаточно заметный эффект (в некоторых ситуациях он может быть и отрицательным)... Тонким "тюнингом" прокачать можно и то и другое... Холиварить не буду - при необходимости в нете можно найти бенчи (в т.ч. и от Andreyka) и рекомендации по настройке.. /естественно, задачу отдачи статики на Apache не вешаем./
Так ТС вроде утверждает что бд тормозит. Не из статики же ее дергают.
Теперь запросы SELECT стали заметно медленнее работать
А покажите ка нам свои запросы (логи медленных запросов)
Ну вот, теперь еще и тяжелую артиллерию включили
У mysql есть тип HASH - использует RAM, пробуйте хранить счетчики там
У mysql есть тип HASH - использует RAM, пробуйте хранить счетчики там
Тип чего, простите? о_О
Видимо, речь о MEMORY (которые HEAP) таблицах..
У них есть недостаток - при перезагрузке/выключении сервера данные пропадают.. Вариант "переписать" с периодическим переносом/обновлением данных в "постоянную" таблицу - вполне приемлем.. Но ведь это менять архитектуру нужно и скрипты переписывать (либо костылями обвешиваться) - опять же не "админское" решение...
А покажите ка нам свои запросы (логи медленных запросов)
+1 за slow_query_log
Есть медленные. В таблице под 700тыс записей, когда-то было больше но из за вылета винта стата за последние 2 месяца не сохранилась - так что записей реально меньше чем было. Никогда тормозов не было.
SELECT * FROM plmon WHERE ip='6340****2' AND name='****' AND proto='48' AND auth='********' AND authprov='4' ORDER BY id LIMIT 1;
# Query_time: 30.587146 Lock_time: 0.000056 Rows_sent: 1 Rows_examined: 686024
SELECT * FROM plmon WHERE ip='29763****8' AND name='****' AND country='RU' AND proto='48' AND auth='*********' AND authprov='4' ORDER BY id LIMIT 1;
# Query_time: 32.598488 Lock_time: 0.000064 Rows_sent: 0 Rows_examined: 686312
SELECT * FROM plmon WHERE name='********' AND country='PL' AND proto='47' AND auth='********' AND authprov='1' ORDER BY id LIMIT 1;
Но мне нужна именно выборка по критериям потому как можно сократить количество этих запросов идей нет.