- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть одна база MYSQL, более 10 миллионов строк, размер дампа 3 ГБ. Вертится на 6 ядерном XEON, 128 ГБ ОЗУ, массив RAID 6.
My.cnf оптимизирован по-максимуму. Mysqltuner отвечает что все ОК, ни одного замечания.
Но проблема в том, что база отвечает на любой запрос от 3 секунд и более.
Если работать в незакешированном месте, например будучи авторизованном в админке, то работать с такими тормозами невозможно. На некоторые сложные запросы (например страница с количеством постов на всем сайте) вообще отвечает 500 ошибкой.
По slow-query наиболее долго обрабатываются запросы COUNT(*), но их не оптимизируешь, т.к. они создаются CMS.
На простые запросы вроде SELECT с id поста ответ по 2-3 секунды.
Я серьезно не понимаю, почему она тормозит. Всякие хайлоуды же за доли секунды делают выборку из терабайтных баз.
Не понимаю почему если размер всех буферов и самого процесса в памяти в несколько раз превышает размер базы, что мешает мускулу всю базу поместить в ОЗУ и работать с ней, а на диск писать только изменения? В ОЗУ любой запрос независимо от сложности должен выполняться за доли секунды :idea:
Причин много. Возьмите проблемный запрос, включите профилирование в phpMyAdmin и посмотрите какие его этапы дольше всего выполняются. Если хочется базу в ОЗУ запихать, используйте InnoDB.
1. Перевести в innoDB и дать ей больше памяти т.е. 6 ГБ вполне можно выделить чисто под них.
2. Переехать на SSD
3. Проверить запросы и индексы в таблицах
Всякие хайлоуды же за доли секунды делают выборку из терабайтных баз
Никакой "хайлоуд" не будет выполнять аггрегирующие функции, типа COUNT(*) в здравом уме
Никакой "хайлоуд" не будет выполнять аггрегирующие функции, типа COUNT(*) в здравом уме
Да не это тормозит… Этот запрос раз в день выполняется за 1000+ секунд и сбрасывает результат в кеш…
Тормозит вся база, ЛЮБОЙ простой запрос на выборку и я не могу понять в чем дело…
Базы в Innodb все давно и все кеши и буферы по-максимуму… Нагрузка на процессор, i/o не более 5% не понятно что им мешает ответить мгновенно или нагрузиться на 100%... Вначале грешил на Wordpress и кривые самописные модули с утечками памяти, но после бенчмарков выяснилось что проблема не в них а в самой базе...
Всякие хайлоуды же за доли секунды делают выборку из терабайтных баз.
Примеры выборок в студию. Если там LIMIT X,X - то запросто тормозить будет, так как в хайлоаде такое не используется.
ЛЮБОЙ простой запрос на выборку
Вот прям любой? Даже select * from user where user = 'root' and host = 'localhost'?
см. explain
Не факт, что это хорошо
My.cnf оптимизирован по-максимуму. Mysqltuner отвечает что все ОК, ни одного замечания.
Возможно максимум превышен как раз. mysqltuner такого не заметит. Покажите my.cnf
В частности, если под кэш запросов выделено слишком много памяти, то мускул сойдет с ума пытаясь кэшировать и искать каждый запрос по каждому чиху. И так далее.
На простые запросы вроде SELECT с id поста ответ по 2-3 секунды.
Индексы-то не слетели?
Я серьезно не понимаю, почему она тормозит.
В phpmyadmin выполните самый простой запрос (select с id поста), потом поставьте галочку "профилирование" и покажите результат.
Не понимаю почему если размер всех буферов и самого процесса в памяти в несколько раз превышает размер базы, что мешает мускулу всю базу поместить в ОЗУ и работать с ней, а на диск писать только изменения? В ОЗУ любой запрос независимо от сложности должен выполняться за доли секунды ☝
Если операции записи частые и ключи при этом затрагиваются, попробуйте в my.cnf выставить delay_key_write=ALL , и добавьте тогда myisam_recover_options=BACKUP,FORCE заодно.
Кроме того, раз у Вас действительно оперативы до фига, а база относительно небольшая, то можно пойти простым путем - сделать временный диск в памяти и размещать рабочую базу мускула именно на нем (не забывая разумеется либо бакапить периодически на жесткий диск, либо вести бинари лог на хдд, либо настроить репликацию хдд-шную базу).
Нагрузка на процессор, i/o не более 5% не понятно что им мешает ответить мгновенно или нагрузиться на 100%...
Значения innodb_thread_concurrency, innodb_file_per_table и tmp_table_size в my.conf какие?
Отключите кеш :)
explain проблемных запросов покажите