NotSlow

да нет там никакого ддос'а при реальном ддос ip адрес сервера полностью отрубают почти сразу. и даже при чем-то простом (в пару тыс запросов/сек) его бы уже давно отключили от хостинга, попросили бы съехать или вообще, или на vps. а судя по описанию, там просто превышение нагрузки периодически. от чего? очевидно от плохо сделанного сайта + наплыва каких-то ботов. и потому первое что надо делать (ну помимо того что сайт до ума довести, чтоб он не генерировал страницы дольше 0.1сек) - просмотреть логи, выяснить что происходило в моменты превышений/падений. наверняка окажется какой-то бот бомбил и достаточно заблокировать его и плюс пачку других известных. или добавить сразу антибот защиту, или через cloudflare пропускать траффик и там ботов фильтровать. плюс в случае каких-то более серьезных всплесков иметь под рукой кнопку "under attack" в cloudflare. ну а бэкдоры - это отдельная тема, совершенно не связанная с ддос из вне. если действительно есть - зачистить и попытаться выяснить откуда взялись (по логам и датам изменений файлов). наверняка самостоятельно и занесено было - установкой варезного чего-то или после пускания на хостинг каких-то сомнительных фрилансеров.

Так может ничего и нет? Вы меньше верьте на слово кому-то одному. Начать нужно с изучения логов. Ну или просто не морочить голову, а обратиться к кому-то с опытом.

так единственное за чем вы следите - время отклика? не ведется никакой статистики, графиков? возможно например поднялась почему-то cpu нагрузка - был бы график, вы бы заметили что да, после 10го. а иначе может это совершенно не связанные вещи, тормоза и обновления 10го. ну даже без графиков, просто что сейчас по нагрузке надо посмотреть. и было ли так раньше. плюс сервер в смысле vps или выделенный. может на выделенном что-то по настройкам энергосбережения поменяли нечайно - вот cpu и еле шевелится... тоже как вариант

ваш шанс состряпать такой модуль из одного mysql запроса... и продать вот человеку за $13

значит надо обратиться к кому-то, кто разбирается.

значит всеж подтягивает и ваш php.ini в корне т.е. выходит лимит в 1гб и все равно мало, а если еще больше там поставить? в phpinfo отразится? ошибка не уйдет?

Не переходите... нам то что? Вы если кроме себя не хотите других слушать, то чем помочь? Про переход на vps никто тут не говорил. Если ваши чемоданы не помещаются в кабриолет, то можно же попробовать универсал (а не грузовик сразу). Нравится именно кабриолет? Ну так ездите дальше. Вопрос к производителю - почему у них такой маленький багажник, когда у большинства других сильно больше. И про то что php.ini ваш не влияет я также не утверждал, а лишь предполагал. Ни сайта вашего, ни хостинга никто не видел, как там устроено кто знает... Влияет или нет - говорю же, откройте phpinfo и посмотрите, подхватывается ли он. Если нет, то какой подхватывается и дальше есть ли у вас доступ изменить его.

В котором php.ini? Тот что в корне сайта? Он почти наверняка ни на что не влияет. Сделайте файл с любым именем, например i.php с текстом: <?phpinfo();?> Откройте его браузером и в самом верху будет указано какие конфиг файлы (php.ini) в каких папках подгружаются и используются Там же ниже поищите (Ctrl+F) строчку memory_limit - это столько сейчас выделено.

Это после обращения в поддержку ему сделали меньше Чтоб скорей перешел на vps и там сам разбирался

Насмехаться конечно легко Но давайте чуть подробностей добавлю, а то совсем заплевали специалисты местные. Вопрос как изначально стоял напомню - "освободить место на хостинге". Т.к. отведенные 30гб закончились и человек просто не хотел переходить на еще выше тариф. Специалистом (по opencart именно) себя ни в коем разе не считаю, но по вопросам связанным с хостингом, найти чем именно занято место - тут без проблем и потому вызвался бесплатно взглянуть (в итоге конечно человек чуть отблагодарил, хотя я не просил). Если бы оказалось, что дело не в банальных логах/бэкапах, а в фотках например, в том, что нужно уменьшать количество вариаций размеров и т.д. - я бы и не взялся (о чем сразу и написал кстати). В данном же случае все оказалось очень просто - 26гб занимал единственный файл с огромной кучей notice и warning. Большинство из которых происходило из шаблона. Файл удалил и через небольшое время он снова несколько мб размером... Очевидно, что за бесплатно вникать почему там в куче мест undefined index, должно ли там что-то быть в тех местах или что-то не так еще выше - это не мое дело. Тут скорей вопрос к тому кто делал сайт изначально, почему такой бардак оставлен был. Ну и главное - изначальная задача решена - место на хостинге уменьшено. Да так, что удалось тариф сильно понизить (уже выгода в деньгах приличная). Да, отключение этого лога может и не правильно, но давайте по честному - никто за годы туда не заглядывал и врядли когда будет Там не было критических fatal error, а только notice в основном. Если всех все устраивало, то будет устраивать и дальше. Оставлять лог включенным (не решая вопрос с источником тех предупреждений) означало бы, что через время он снова бы разжирел и снова бы место закончилось. Владелец конечно вправе (если будет желание) к кому-то другому обратиться (вопрос еще сколько запросят за правильное решение вопроса ув. специалисты), включить опять тот лог и поисправлять все проблемные места по сайту. Да, и все 26гб я конечно не просматривал. Возможно когда-то в прошлом был сильный всплеск какой-то дичи, а сейчас уже лучше. Но все равно он заметно увеличивался в размерах на глазах.

А если все нужное? Откровенно ненужное - это какие-то логи, бэкапы, архивы забытые. Но если там просто в папке image все эти 30гб, то мало что можно сделать

Ну вам же там пишет, что JIT для php 8.0 и выше, а у вас 7.2 Сколько памяти (opcache.memory_consumption) - кто ж вас знает... включайте сколько есть и через время смотрите в phpinfo: Если free memory будет 0, то будет много cache misses - значит стоит добавить. Время проверки изменений (opcache.revalidate_freq) можно оставить default (2)

Да, но 99%, что это именно от php нагрузка. https://www.pyn.com.ua/info.php Там не включен opcache https://linuxblog.io/php-benchmarks-opcache-performance-tweaks/ Время ответа с вкл и выкл обычно всегда отличается радикально. Ну и нагрузка на cpu также сильно больше с выключенным. Это первое что бросилось в глаза, потому и спросил зачем оно выключено?

Судя по графику, у вас нагрузка от php в 2 раза выше, чем от mysql. Может стоило бы с этим сперва что-то сделать, а потом уже с базой. Подозреваю, что в основном нагрузка от того, что у вас opcache в php выключен. Есть ли причина почему?

Ну а вам бы понравилось если б на какой-то левой vps неизвестно кто-то пытался слать какие-то письма от имени вашего домена? Причем вам же. Просто надо по-человечески настроить все что касается почты на вашем домене и вашей vps. Возможно дело не в OC вашем и даже не в vps, а к примеру на уровне хостера заблокирована отправка почты. Это как один из вариантов. Нужно смотреть...

действительно вот эта страница https://maxbox.ua/index.php?route=checkout/oct_fastorder в ответ отдает лишь location https://maxbox.ua/index.php?route=checkout/oct_fastorder получается бесконечный редирект на саму себя. а почему она это делает - надо смотреть :-\

в одном и том же месте? или рандомно в разных случается такое? сталкивались с подобным многие, но вам от этого легче не станет. нужно конкретно вашу проблему увидеть хотябы. чаще всего это из-за принудительных редиректов с www на без-www например или с http на https и когда конечная страница редиректит зачем-то обратно. получается зацикленность. когда в cms сайта указано http, а в .htaccess стоит редирект на https и в таком духе. но обычно тогда все страницы в подобных ошибках. вы же говорите что все ок в основном, но иногда случается. еще вариант (почему нет) вы браузер 2 месяца не перегружали и какие-то страницы он из кэша берет с редиректом (которого на самом деле уже нет) в общем - к гадалкам

Ну вот и смотрите на что оно ругается. Главная проблема в том, что письмо на самом деле отправляется от имени: И следующая ошибка проистекает от этой - что MX записи нет у домена отправителя. Это на уровне настроек хоста лечится, а не в opencart. Плюс записи DMARC и SFP надо бы правильные сделать. Что тоже вне рамок самого сайта - в DNS делается.

Решение есть Какой вопрос - такой ответ. Слишком много неизвестных. Вы можете например организовать отправку подобного письма сюда: https://www.mail-tester.com/ (копируете сгенерированный email, шлете письмо и потом жмете кнопку оценки). Что в итоге получится можете скинуть сюда (там потом будет ссылка дана на отчет) или хотябы скринами показать нам. Иначе можно что угодно фантазировать сейчас без вводных данных.

Проблемы особо нет на самом деле. Точно также фрилансер от фтп себе сохранит доступы. Ничего не мешает после фрилансера поменять пароль. Как на фтп, так и в файле этом. А от фрилансера куда большего подвоха можно ожидать в виде где-то глубоко спрятанного шелла. "Найти" тоже малореально, если обозвать своим уникальным именем. Кроме того, если это на vps своей, то можно ftp вообще отключить даже, т.к. не факт что кто-то озаботился защитить его от брутфорса паролей.

как вариант: https://github.com/alexantr/filemanager задайте в нем свой логин/пароль. в папку admin себе закиньте или еще лучше внутри подпапку с уникальным каким-то именем создайте и туда. будет не прям из админки opencart конечно, но сохранить в закладки себе путь к нему осилите думаю.

А что именно уже делалось по этому поводу? Зачем вам советы, которые вам уже не актуальны. Кто-то смотрел от чего именно нагрузка? Какой смысл советовать запросы к базе оптимизировать, если у вас там php скрипты создают нагрузку например. Если база, то включался ли лог медленных запросов? Выяснялось ли из каких скриптов/модулей сайта эти запросы приходят? Может тяжелых запросов нет, но просто быстрыми мелкими очень активно долбит... откуда именно, опять же. Советы по настройке сервера вам тоже возможно ни к чему, если вы на shared хостинге сейчас. Слишком много неизвестных. Волшебных хаков, не ускоряя сами тормоза сайта, всего два: 1) Увеличить скорость "железа", на котором сайт работает. Не какой-то там тариф по-выше, не ядер каких-то там по-больше, а именно скорость cpu, однопоточную. 2) Добавить модуль кэширования. Тормозить будет все также, но хотябы сгенерированное будет сохраняться и какое-то время отдаваться в готовом виде. Этим и снижая нагрузку общую.

да спамеры чаще всего используют нормальные user agent'ы. и ip используются совершенно разные. причем часто со взломанных устройств нормальных людей. т.е. банить провайдерские ip - такое себе... надо именно отличать нормальный браузер человеческий от скриптовых/программных ботов. капча конечно более надежна, но и более раздражающая

И это только то что вы замечаете. А сколько постоянно по сайтам ботов долбится по всевозможным скриптам, админкам и т.д... У меня практически у всех клиентов сайты под защитой на любые POST запросы. Нормальные люди заходят везде как обычно, и безо всяких разгадываний капч. А боты лишь 403 ответ получают от nginx, даже не напрягая apache/php этим мусором:

километровый .htaccess будет немного замедлять все. еще вариант - повесить домен на cloudflare и там настроить защиты