- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Если это все на HDD, удивительно, что это занимает только 3 секунды.
Фигня что вся база со всеми совими индексами влазит в оперативку 😂
Были случаи что помогало переключение с tcp на сокеты или наоборот. С индексами у меня в табличке на 400КК строк запросы выполнялись менее чем за 1 секунду, при том агрегирующие, в таблице которая превышала озу в 4 раза. Но и было когда тупило по 20 секунд на 100 000 строках, если мимо индекса промахивается.
Как уже сказали, надо видить какие то цифры, графики, результаты :)
Есть одна база MYSQL, более 10 миллионов строк, размер дампа 3 ГБ. Вертится на 6 ядерном XEON, 128 ГБ ОЗУ, массив RAID 6.
My.cnf оптимизирован по-максимуму. Mysqltuner отвечает что все ОК, ни одного замечания.
Но проблема в том, что база отвечает на любой запрос от 3 секунд и более.
Если работать в незакешированном месте, например будучи авторизованном в админке, то работать с такими тормозами невозможно. На некоторые сложные запросы (например страница с количеством постов на всем сайте) вообще отвечает 500 ошибкой.
По slow-query наиболее долго обрабатываются запросы COUNT(*), но их не оптимизируешь, т.к. они создаются CMS.
На простые запросы вроде SELECT с id поста ответ по 2-3 секунды.
Я серьезно не понимаю, почему она тормозит. Всякие хайлоуды же за доли секунды делают выборку из терабайтных баз.
Не понимаю почему если размер всех буферов и самого процесса в памяти в несколько раз превышает размер базы, что мешает мускулу всю базу поместить в ОЗУ и работать с ней, а на диск писать только изменения? В ОЗУ любой запрос независимо от сложности должен выполняться за доли секунды ☝
Как вариант попробуйте создать Ram диск на 4 Гб или больше если размер базы больше и потестировать оттуда , но помните что после перезагрузки сервера ваш рам диск очистится.
Это только для тестов, так вы поймете дело в вашем Raid 6 или в конфигурациях и структуре базы.