Авіафорум - авіаційний форум

С виртуального хостинга попросили, потому что было превышение по ресурсам процессора CPU. В итоге на VPS постоянно какие-то проблемы с RAM.

Посмотрите по логам что происходит.
Скорее всего тот же BING валит сайт (ддосит по другому не назовешь).
В robots.txt
добавить:
User-Agent: bingbot
Crawl-delay: 10
P.S. По вашей проблеме. Сайт валился из-за нехватки ресурсов. Т.е. Вы грубо говоря полностью израсходовали ОЗУ, сервер что бы спастись освобождает память - убивая процесс MySQL. В итоге имеем битые таблицы (из-за того что mysql процесс убился) и неработающий mysql. Стандартно стоит перезапуск 15мин (в isp панеле - мониторинг сервисов), т.е. сайт пытался скорее подняться либо поднимался, но в связи с тем что таблицы по@ерились адеватно не вставал + продолжалась долбежка того же bing'a вызывая нагрузку и RIP обратно

Спасибо.
Написали, что в похожее время был ScooperBot/3.0 с запросом 340 страниц в минуту. Это тоже может вызывать ошибку?

https://ruhighload.com/mycnfexample?ram=4 - после прочтения сжечь)

От себя, зайдите в phpmyadmin забейте show full processlist - если есть спящие процессы, значить надо оптимизировать запросы. Можно пойти путем временной правки, т.е. задать выкидывание ошибки тому кто сильно "много просит".
т.е. в том же my.conf
раздел [mysqld]
Добавить:
interactive_timeout=120
wait_timeout=120

Т.е. если сайт не переварил за 2 минуты запрос - выкинуть из БД спящий запрос.
Иначе получите что память закончится - получите смерть службы.

Olek писав: ↑09 грудня 2019, 17:32 Спасибо.
Написали, что в похожее время был ScooperBot/3.0 с запросом 340 страниц в минуту. Это тоже может вызывать ошибку?

Так это оно и есть))

User-agent: ScooperBot
Disallow: /

У меня CWP7 панель.

В настройках еще такое
php.ini configuration
max_execution_time 3000
max_input_vars 100000

Это что такое?

mysqlnd

Command buffer size 4096
Read buffer size 32768
Read timeout 86400

И еще одно наблюдение. Сейчас мне тоже выдало ошибку связи с базой данных при заходе на часть сайта на wordpress. Обновление страницы решило проблему. По данным панели управления, в это время было занято 1,4ГБ из 4ГБ. С чем такое эпизодическое выпадение ошибок связано?

Olek писав: ↑09 грудня 2019, 17:46 У меня CWP7 панель.

В настройках еще такое
php.ini configuration
max_execution_time 3000
max_input_vars 100000

Это что такое?

max_input_vars 100000 - это кол-во полей, которые PHP может принять за 1 раз, по дефолту стоит 1000 и их реально бывает не хватает) но 100к это сильно) я бы больше 10000 не ставил
max_execution_time 3000 - это кол-во времени выполнения PHP, т.е. если я сейчас зайду на сайт и сервер "думает", страницу я могу ждать 50 минут. Это кто сделал по ушам бы дать)) На уровне фронтенда (не админки), ставить не больше 2мин т.е. 120сек. Единственное теоретически могут сделать такую гадость только в том случае если карта сайта генерируется не на лету, а при обращении и думает 10500 минут - надо проверить.

P.S.
смотрите в чем у вас косяк:

• пользователь открывает страницу сайта
  на сервер приходит запрос
  Сервер посылает запрос PHP
  PHP подключается к MySQL
  PHP направляет SQL-запрос в MySQL
  MySQL выполняет запрос и отдает результат в PHP
  PHP закрывает соединение с MySQL
  PHP формирует контент и отдает его в Apache
  Apache посылает ответ в браузер

Так вот у вас стоит max_execution_time 50минут, т.е. бот залез и открыл 340 страниц в одно и тоже время, на этапе "MySQL выполняет запрос и отдает результат в PHP" - в вашей ОЗУ висит это все и ждет результат, MySQL сервер не отвечает так как у него еще 300 запросов в эту секунду залезло, все они выполняются ПОСЛЕДОВАТЕЛЬНО. Итого имеем каждую секунду запросов больше, все они на уровне PHP выполнились, но ждут ответа от MySQL что бы дать ответ, получается что вся ваша память занимается хранением этих запросов-ответов где есть и все переварить не может и получаем "бум эффект" в виде смерти службы mysql.

в случае с max_execution_time маленьким (по дефолту кстати 30сек), сервер бы через 30 секнд закрыл соединение по таймауту, чем бы скорее и не дал серверу погибнуть из-за нереальной очереди

Read timeout 86400 - это время которое сервер может обрабатывать 1 запрос. Т.е. то на уровне PHP настройка, а это на уровне БД(MySQL). Обратно таки это из разряда мазахиста)

Olek писав: ↑09 грудня 2019, 18:06 И еще одно наблюдение. Сейчас мне тоже выдало ошибку связи с базой данных при заходе на часть сайта на wordpress. Обновление страницы решило проблему. По данным панели управления, в это время было занято 1,4ГБ из 4ГБ. С чем такое эпизодическое выпадение ошибок связано?

надо сделать профилатику таблиц, скорее кое где битые стали. Если у вас MyISAM таблицы - тогда вам сюда как мунуал http://www.mysql.ru/docs/man/REPAIR_TABLE.html

Т.е. проблема может быть еще в этих настройках?
php.ini configuration
max_execution_time 3000
max_input_vars 100000

На общем хостинге стояло

php.ini configuration
max_execution_time 300
max_input_vars 1000

Если поставить

php.ini configuration
max_execution_time 300
max_input_vars 5000

Это может решить проблему?

Проблема в ботах, они тупо нереальную нагрузку делают. То что мы обсуждаем технические настройки - это нужно изменить конечно, но в случае с ботами - поможет если только у вас ресурсов хватит на сервере)
Говорю же эти пауки, спайдеры, боты они тупо ддосят сайт своими запросами. На данный момент вам важно "обрезать" этих ботов добавлением в файл robots.txt строк конфигураций для них (писал выше)

https://ru.wikipedia.org/wiki/%D0%A1%D1 ... 0%BE%D0%B2

Попробуйте всем задать кроме Яши. (гугл просто не смотрит на параметр Crawl-delay )

User-agent: *
Crawl-delay: 10

Поддержка ответила, что заблокировала с десяток второстепенных ботов, проверила на ошибки базы данных и исправила. Наблюдаем дальше. Спасибо за помощь.

admin порав шаблон сторінки. Під час експорту попереднього перегляду у Фейсбук внизу з'являється інформація про фото, замість якогось корисного тексту. Може це так і задумано, але краще б там було щось корисне.

mischko писав: ↑12 грудня 2019, 15:31 admin порав шаблон сторінки. Під час експорту попереднього перегляду у Фейсбук внизу з'являється інформація про фото, замість якогось корисного тексту. Може це так і задумано, але краще б там було щось корисне.

Поясніть, що ви маєте на увазі, зі скріном.

Olek писав: ↑12 грудня 2019, 15:54

mischko писав: ↑12 грудня 2019, 15:31 admin порав шаблон сторінки. Під час експорту попереднього перегляду у Фейсбук внизу з'являється інформація про фото, замість якогось корисного тексту. Може це так і задумано, але краще б там було щось корисне.

Поясніть, що ви маєте на увазі, зі скріном.

Обвів червоною рамкою, що мені не подобається. Гадаю, треба погратися з розміткою, тут описано, що треба поправити: https://developers.facebook.com/docs/sh ... ebmasters/

На данный моментг (де-то семь вечер 25 марта 2020) весь форум Off откатился назад показывает сообщения по состоянию на 3 марта 2020. Возможно этот глюк только у меня, но мало ли...