- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всё началось с того что я увидел резкий всплеск нагрузки на CPU на ВПС.
top показал страшные вещи
Полез разбираться с мускулем.
Увидел, что нагрузка идет от разрабатываемого, по сути нерабочего сайта.Ну ладно, долго не заморачиваясь, я просто отключил этот сайт в ISPпанели.
Однако mysqladmin processlist status по прежнему показывает подобную простыню
Что странно, тк этот эта база работает только на отключённом сайте и никто подобные запросы делать не может. (или же я чего-то не понимаю? Другие коннекты к базе очень маловероятны, внешнее подключение отключено)
В общем как это дело остановить без ребута сервера?
ID процесса одинаковый или новые прилетают?
KILL [PROCESS-ID] не помагает?
На всех сайтах одинаковый пользователь?
В общем как это дело остановить без ребута сервера?
Ребутнуть mysql?
Ребутнуть mysql?
Не хотелось бы. Во всяком случае не сейчас - там ещё рабочий ИМ и сейчас самый пик.
kill
Я немного неудачную строку скопипастил. Там преобладает
И вот судя по Storing result in query cache наверняка можно что-то с кешем сделать.
Не хотелось бы. Во всяком случае не сейчас - там ещё рабочий ИМ и сейчас самый пик.
Я немного неудачную строку скопипастил. Там преобладает
И вот судя по Storing result in query cache наверняка можно что-то с кешем сделать.
1. Вы в 2023 используете кеш mysql?
2. Вы в 2023 используете
?
Вы в 2023 используете
Да, я использую то, что написано/настроено специалистами. И пож. покинь топик. Конкретно твоя "помощь" мне не нужна.
А, окей.
У Вас запросы по идее по 2 недели выполняются.
Все.
П.С.
Вы себя ведете как те, кому Вы помагаете.
Подумать, нужен ли он, особенно если БД в InnoDB формате.
А лучше выключить и если надо кэш реализовать на базе CMS.
Ещё вариант кэш Mysql (если уж сильно хочется), должен быть миниатюрным, а не по 1 ГБ и даже не 256 МБ как я не раз видел от "профессионалов" "оптимизаторов".
Ну и версию Mysql бы узнать.
Подумать, нужен ли он, особенно если БД в InnoDB формате.
В таких тонкостях я не в теме (можно сказать мускуль я знаю только на уровне "написать запрос" и "выгрузить дамп"). Когда сервак ставили я написал требования которые знал что мне нужно и отдельно просил чтобы настроили чего я не написал/не знаю. (Позже оказалось что даже то что просил не сделали нормально. Просто в панельке пару кнопок тыкнули и по сути всё)
И кроме того так же устанавливает панель...
Думаешь стоит отключить если крутится WP+WooCommerce?
Ну и версию Mysql бы узнать.
Машка 10.3.29
Панель никак не относится к формату хранения данных. Это уже сам разработчик делает.
Если WP, то там явно будет InnoDB, если WP новый.
10.3.29
Что-то старенькая. Не обновляется что-ли сервер?
Да, можно выключить кэш запросов и посмотреть, что будет. Но ещё надо уделить внимание настройками БД, особенно innodb_buffer_pool_size, он должен быть чуть больше, чем размер данных всех на сервере БД.