- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Довольно интересная проблема с cron скриптом (php, mysqli).
Общая схема работы: SELECT DISTINCT поле-ключ FROM TABLE WHERE ...
Это отрабатывает за 4 секунды. Далее
while ($row=mysqli_fetch_assoc($result))
в цикле из базы выбираются записи относящиеся к значению из 1го запроса и обрабатываются, длится это в данном случае 15 секунд, после чего в базу должны быть проведены UPDATE и DELETE запросы но они не удаются по причине MySQL server has gone away. Через 19 секунд после старта. wait_timeout стоял 30 секунд, сделал 60 - толку нет.
После подключения к БД ставлю SET session wait_timeout = 180 - результата нет. 19 секунд!
Поставил проверку if !mysqli_ping() и делаю реконнект - выдавало false, реконнект вроде как удается, последующий UPDATE запрос - ошибка. Поставил в php.ini автоматический реконнект - mysqli_ping после 18-19 секунд работы скрипта выдал true но следующий запрос опять же MySQL server has gone away
В чем может быть проблема?
Может проблема в запросе, а не в MySQL и его конфигах?
А эта ошибка может возникать из за запроса вместо стандартной ошибки что ожидалось что-то после чего-то а получено не то?
Ок ща еще немного дебага добавлю.
p.s. в логах пусто, предел по памяти не достигается но все равно понаставил промежуточных mysqli_free_result
-------------
Да, тему в утиль. Был слишком длинный запрос по последним 2 значениям которые все никак не могли обработаться,
распилил частями и все прошло.
Вообще ситуация была внештатная - данные за 10 дней насобирались при том что планируется регулярная обработка поступающих данных несколько раз в сутки. Можно считать это краш тестом под нагрузкой.
Хорошо, что все получилось)
Подобная ошибка возникает иногда из за длинных запросов, уже неоднократно сталкивались с этим)
ерез 19 секунд после старта. wait_timeout стоял 30 секунд, сделал 60 - толку нет.
А по-дефолту это значение - 28800.
Не надо ничего "оптимизировать" в mysql без необходимости.
8 часов чтоли? У меня были случаи состояния denial of service БД по причине сотен висящих в SHOW PROCESSLIST запросов, уже не помню что и когда, но обычно такие вещи ограничиваю. Сайт должен работать быстро, если что-то подвисло оно должно мирно вылететь у одного посетителя или бота, и не влиять на остальных.
Metal_Messiah, эта настройка в описанной вами ситуации не поможет. По крайней мере не в той степени, в которой вы думаете. Запросы не останавливаются при обрыве соединения. А минус уже есть - вы попали в странную непонятную ситуацию. То есть, вообще практически никакого смысла трогать эту настройку нет.
Но ошибка покажется быстро, да.
Для ограничения нагрузки лучше обработчики php регулировать, а не mysql.
Как вариант, можно было попробовать max_allowed_packet увеличить в my.cnf