1040 ошибка mysql

[Alnico]

Форум стал работать со сбоями, падает mysql, выдает ошибку 1040,
что может говорить о превышении лимита запросов.
Непонятно, откуда могут идти запросы?
От какого-то скрипта самого форума? Или все же большое количество внешних подключений (боты!),
что заметно по логам, хотя запросов не так много, в основном ломится некий Амазон-БОТ, по 20-30
запросов в минуту.
Сначала было так по утрам, а теперь постоянно.
В .htaccess вообще блокирую все боты, а так же все диапазоны IP откуда могут идти запросы.
Нагрузка уменьшается, но ошибка 1040 остается.
Что можно сделать?

[Татьяна5]

Ограничить или вообще заблокировать (если не нужен) того бота

[Alnico]

Ограничить или вообще заблокировать (если не нужен) того бота

Увы, не помогает. Заблокировано все что можно, трафик почти нулевой, а ошибка 1040 остается.

[rxu]

Чему равно max_connections в настройках MySQL?
Какая версия phpBB? Версия MySQL?
Что менялось на сервере, после чего появилась ошибка?

[Alnico]

Чему равно max_connections в настройках MySQL?,
Какая версия phpBB? Версия MySQL?
Что менялось на сервере, после чего появилась ошибка?

phpBB 3.1.7-PL1
MySQL 5.0.90
И ничего вообще не менялось, началось с того, что в логах стало появляться большое количество запросов
с IP адресов Amazon, до 200-300 запросов в минуту.
В конфиге MySQL, в файле my.cnf вообще не было max_connections, но после наплыва ботов,
это первое что я сделал: поставил значение max_connections = 500, но это никак не помогло.
MySQL по прежнему то работает, то падает.

Дополнительно: если отключаю доступ на форум полностью в htaccess или на уровне виртуальных хостов Апач, то MySQl перестает падать!

[Михаил Молчанов]

У меня тоже нашествие гостей.
Вот недавно рекорд был.
Больше всего посетителей (1418) здесь было Ср 15. янв 2025
Я бы посоветовал поставить последнюю версию форума. Последнюю версию php и последнюю версию msql

[Alnico]

Я бы посоветовал поставить последнюю версию форума. Последнюю версию php и последнюю версию msql

К сожалению в данное время это невозможно, так как последняя версия форума требует PHP7 или PHP8.
А сменить версию PHP нельзя, так как это потребует смены "железа" и операционной системы сервера.

[capur]

доброго времени суток, помогите решить проблему, которая я так понимаю лежит в той же плоскости что здесь описано:
в последние 3 дня увеличилось многократно кол-во гостей (счет идет на тысячи), в итоге форум замедлился, а потом и вовсе упал. Обратился к хостеру, тот выдал следующий вердикт

Код: Выделить всё

Reading 2025-07-20...
Apache Access: Processing 431885 strings of Access Log...
PHP RUSAGE: No processing logs by reason: ##No data for this log##

Working...
Processed 431885 strings
Top 2 of 2 domains:
-------------------------------------------
 431884	100.00%	**********.beget.tech
 1	0.00%	www.**********.beget.tech

Top 5 of 370033 IPs:
-------------------------------------------
 5586	1.29%	95.37.58.234     - Russian Federation, Mulino
 3026	0.70%	95.26.65.33      - Russian Federation, Voskresensk
 972	0.23%	212.90.62.163    - Ukraine, Kiev
 449	0.10%	23.249.172.173   - United States, Los Angeles
 372	0.09%	151.0.53.165     - Ukraine

Top 5 of 726 User-Agents:
-------------------------------------------
 5624	1.30%	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 OPR/119.0.0.0
 5610	1.30%	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
 3026	0.70%	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 YaBrowser/25.6.0.0 Safari/537.36
 2318	0.54%	Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
 2235	0.52%	Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36

Top 2 of 2 METHODs:
-------------------------------------------
 426510	98.76%	GET
 5375	1.24%	POST

Top 5 of 726 User-Agents:
-------------------------------------------
 5624	1.30%	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 OPR/119.0.0.0
 5610	1.30%	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
 3026	0.70%	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 YaBrowser/25.6.0.0 Safari/537.36
 2318	0.54%	Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
 2235	0.52%	Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36

Top 2 of 2 METHODs:
-------------------------------------------
 426510	98.76%	GET
 5375	1.24%	POST

Top 2 of 2 Dates:
-------------------------------------------
 431879	100.00%	20 Jul 2025
 6	0.00%	19 Jul 2025

Top 5 of 408032 Requests:
-------------------------------------------
 4474	1.04%	GET	***********.beget.tech/app.php/bb3topics_ajax?page=0&forum_id=&block_ids=0&options=
 4142	0.96%	POST	*************.beget.tech/app.php/mchat/action/refresh
 1091	0.25%	POST	*************.beget.tech/app.php/mchat/action/whois
 222	0.05%	GET	**************.beget.tech/
 180	0.04%	GET	**************.beget.tech/app.php/cron/cron.task.text_reparser.poll_option

Top CPers: (1695.466 total)
-------------------------------------------
 848.539	**************.beget.tech/viewforum.php
 416.712	**************.beget.tech/viewtopic.php
 86.926	**************.beget.tech/memberlist.php
 84.438	**************.beget.tech/search.php
 80.732	**************.beget.tech/ucp.php

И пояснение от хостера: "Как видно из лога, наибольшая нагрузка создается двумя скриптами: viewforum.php и viewtopic.php. При этом основная нагрузка ложится на базу данных."
А также:
"Собрал лог медленных запросов к БД":

Код: Выделить всё

Logs: mysql-slow
Dates: [ 2025.07.21 ]
Database: *********_phpb4

# 15.5s user time, 1s system time, 40.98M rss, 47.90M vsz
# Current date: Mon Jul 21 05:35:14 2025
# Hostname: logstorage3
# Files: /dev/fd/63
# Overall: 70.42k total, 7 unique, 3.50 QPS, 21.92x concurrency __________
# Time range: 2025-07-20T20:59:56 to 2025-07-21T02:35:08
# Attribute          total     min     max     avg     95%  stddev  median
# ============     ======= ======= ======= ======= ======= ======= =======
# Exec time        440871s      2s     11s      6s      9s      2s      6s
# Lock time             3s    21us     2ms    40us    66us    16us    36us
# Rows sent          1.99M       0 414.86k   29.66    0.99   3.21k    0.99
# Rows examine       9.38G 101.84k 829.71k 139.71k 165.97k  21.83k 136.54k
# Rows affecte     415.73k       0 415.73k    6.05       0   1.51k       0
# Bytes sent       112.98M      14  22.83M   1.64k   65.89 184.07k   65.89
# Query size         8.60M      60     466  128.00  124.25    1.54  124.25

# Profile
# Rank Query ID                      Response time      Calls R/Call V/M
# ==== ============================= ================== ===== ====== =====
#    1 0x21453BDE587FDC41171A8AE5... 440813.7410 100.0% 70405 6.2611  0.43 SELECT phpbb_sessions
# MISC 0xMISC                             57.3648  0.0%    16 3.5853   0.0 <6 ITEMS>

# Query 1: 3.50 QPS, 21.92x concurrency, ID 0x21453BDE587FDC41171A8AE59C539C3C at byte 31070729
# This item is included in the report because it matches --limit.
# Scores: V/M = 0.43
# Time range: 2025-07-20T20:59:56 to 2025-07-21T02:35:08
# Attribute    pct   total     min     max     avg     95%  stddev  median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count         99   70405
# Exec time     99 440814s      2s     11s      6s      9s      2s      6s
# Lock time     99      3s    21us     2ms    40us    66us    16us    36us
# Rows sent      3  68.75k       1       1       1       1       0       1
# Rows examine  99   9.38G 101.84k 175.96k 139.63k 165.97k  21.00k 136.54k
# Rows affecte   0       0       0       0       0       0       0       0
# Bytes sent     3   4.50M      67      67      67      67       0      67
# Query size    99   8.59M     128     128     128     128       0     128
# String:
# Databases    ********_phpb4
# Hosts        localhost
# Last errno   0
# Users        *********_phpb4
# Query_time distribution
#   1us
#  10us
# 100us
#   1ms
#  10ms
# 100ms
#    1s  ################################################################
#  10s+  #
# Tables
#    SHOW TABLE STATUS FROM `*******_phpb4` LIKE 'phpbb_sessions'\G
#    SHOW CREATE TABLE `********_phpb4`.`phpbb_sessions`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT COUNT(session_id) AS sessions
                                        FROM phpbb_sessions
                                        WHERE session_user_id = 1
                                        AND session_time >= 1753057628\G

И пояснение: "Как видно, необходимо оптимизировать запросы к вашей БД."

А делее следующее сообщение:

"Мы обнаружили существенное превышение лимитов по нагрузке. Подробные графики по нагрузке.

В качестве экстренных мер по снижению нагрузки мы:
- Подключили механизм защиты через Cookie и Javascript, чтобы отсечь простых ботов
- Заблокировали POST-запросы к сайту.

Эти меры могут нарушить корректную работу сайта. Рекомендуем вам по-возможности найти причину повышенной нагрузки и устранить ее или обратиться в техническую поддержку для помощи."

Естественно ни я, ни пользователи теперь не могут зайти в свои аккаунты (ошибка 403).

Что можно сделать?

[rxu]

При таком количестве запросов никакая оптимизация запросов к БД не поможет.

Заблокировали POST-запросы к сайту.

Согласно их же логам, 98,76% запросов - GET. Бессмыслица.

Что можно сделать

Заблокировать адреса или целые диапазоны, с которых происходит атака, например. На уровне сервера.

[nissin]

Старая проблема с таблицей сессий.
Что обычно делаю:
1) прописываю всех ботов в администраторском разделе форума по user-agent
2) добавляю поле bigint с автоинкрементом в таблице sessions и назначаю его primary index. session_id делаю обычным индексом. Это решает проблемы с медленным добавлением записей в таблицу сессий.
3) анализирую лог медленных запросов и добавляю все возможные индексы в разных комбинациях. В данном случае я бы попробовал создать индекс по полям:
session_user_id, session_time, session_id

[rxu]

я бы попробовал создать индекс по полям:
session_user_id, session_time, session_id

Эти, по-моему, есть по умолчанию, отдельно каждый.

добавляю поле bigint с автоинкрементом в таблице sessions и назначаю его primary index. session_id делаю обычным индексом. Это решает проблемы с медленным добавлением записей в таблицу сессий.

Насколько быстрее становится добавление записей? Может, в ядро это добавить.

[angst66]

А сменить версию PHP нельзя, так как это потребует смены "железа" и операционной системы сервера.

Вы не сказали, что у вас за хостинг. Все это не проблема, если у вас виртуальный или выделеный сервер
.

[nissin]

я бы попробовал создать индекс по полям:
session_user_id, session_time, session_id

Эти, по-моему, есть по умолчанию, отдельно каждый.

Нужно именно одним, он тогда пройдёт только по этому индексу без обращения к данным.
В данном случае это именно оптимизация БД под конкретный запрос.

Насколько быстрее становится добавление записей? Может, в ядро это добавить.

На таблице sessions в 500MB, мгновенное добавление(менее 1 ms) вместо секунд.
Там проблема из-за того что неудачно выбран PRIMARY INDEX и движок INNODB всю таблицу начинает всю таблицу перезаписывать при добавлении записи.
На маленьких таблицах это незаметно, но когда большой объем это вызывает проблему.

[rxu]

начинает всю таблицу перезаписывать при добавлении записи

А почему, есть понимание? И session_id, и автоинкрементое поле оба уникальные, в чем разница при добавлении строк?
Или перезапись таблицы происходит в обоих случаях, но в варианте автоинкремента просто быстрее?

[nissin]

А почему, есть понимание? И session_id, и автоинкрементое поле оба уникальные, в чем разница при добавлении строк?
Или перезапись таблицы происходит в обоих случаях, но в варианте автоинкремента просто быстрее?

INNODB хранит записи в таблице физически отсортированные по первичному ключу.
Посколько session_id имеет случайное значение, то запись добавляется в середину таблицы, и вызывает её пересортировку.
Если поле автоинкрементное, то запись просто добавляется в конец таблицы, сортировка в этом случае не требуется.