Расход оперативной памяти

Вы не увидите РЕАЛЬНЫЕ циферки свободной/занятой памяти всего сервера

Только циферки VDS, которые "виртуальны"

Да и чем они Вам помогут, тут дело в хостере в таком случае, если память кончилась

Ребутнул, вроде бы попупстило.

И как теперь проверить - на чьей стороне правда с памятью?

Впрочем, все равно дело в чем-то ином. Все-таки всю неделю расход небольшой, а тут раз и ОПА.

В том то и дело

Вчера клиентам Вашего хостера не нужна была память, а сегодня кто-то запустил софт, который "съел" память, и у Вас не с того не с сего начали ошибки сыпаться в выделении памяти

Допустим. Тогда какое решение?

1. Запросить больше вирт памяти для себя (читай сменить тариф)? Даст ли это запас ресурсов для меня?

2. Сменить услугу на выделенный сервер? (Столько денег сайт не приносит) или

3. Сменить хостера hc.ru?

И вообще, можно ли это как-то доказать: что хостер жопит память.

1. нет, закажите хоть 1024Гб оперативной памяти, если на ноде доступно 64Гб - больше 64Гб израсходовать нельзя, есть конечно файл/раздел подкачки который и используется в случае нехватки памяти (тогда и все ужасно лагает).

2. Поможет, все ресурсы сервера будут только вашими.

3. Ваше право. Узнать "жопит" разве что косвенно. Запросите график нагрузки сервера, спросите можно ли перенести ваш виртуальный сервер на более загруженную ноду.

vitzer, посмотрите логи - возможно кто-то в это время активно сканировал сайт.

Кроме оптимизации mysql - поставьте кеширование в nginx.

Кэширование включено в настройках домена.

Так что вы скажите господа: исходя из изложенных данных, косяков самого сайта не видно? Или мало данных и все-таки необходимо обращаться за платными услугами к специалистам для более глубокого анализа ситуации?

я имею ввиду не заголовки для кеширования в браузере, а кешироавание того, что отдает бакэнд.

Проблема не с сайтом, а с сервером.

Нужны доступы и анализ, в паблике такого не выложишь) Потому только обращаться к специалистам.

Как вам?

Ниже ответ хостера:

На Вашем VPS зафиксировано превышение некоторых тарифных лимитов:

resource held maxheld barrier limit failcnt

privvmpages 308775 524286 524288 524288 54

Столбец failcnt здесь - число неудачных попыток выделить ресурсы для процессов.

Более подробно с тарифными лимитами и их описанием Вы можете ознакомиться в документе "Технические параметры VPS-хостинга":

https://shop.hc.ru/repgen/oferta?part=5

Причиной превышения может быть как разовое увеличение нагрузки (например индексирование поисковиками или пиковая посещаемость), так и общая перегруженность Вашего VPS.

В данном случае, причиной вероятнее всего является нагрузка, создаваемая поисковыми системами:

[httpd-logs]# cat vvm-auto.ru.access.log | cut -d' ' -f1 | sort | uniq -c | sort -n | tail

499 62.133.162.201

538 37.54.33.46

688 79.135.155.151

890 141.105.66.31

1517 94.231.71.72

1892 127.0.0.1

4229 141.8.132.69

4370 66.102.9.138

4394 66.102.9.136

4591 66.102.9.134

Выше приведены 10 наиболее часто обращающихся IP-адресов ( Кол-во запросов/IP).

4229 141.8.132.69

4370 66.102.9.138

4394 66.102.9.136

4591 66.102.9.134

Все эти IP принадлежат поисковым системам. Соответственно Вам необходимо настроить корректную индексацию сайта, используя например файл robots.txt, например используя функцию Crawl-delay - https://yandex.ru/support/webmaster/controlling-robot/robots-txt.xml#crawl-delay

Для решения данной ситуации следует оптимизировать работу сайта или сменить тарифный план на более высокий из текущей тарифной линейки VPS.

Особенно порадовало:"или сменить тарифный план на более высокий из текущей тарифной линейки VPS." Они все время предлагают сменить тарифный план.

Примерно тоже самое мне пели, когда я месяц назад сидел на тарифном плане "Виртуальный хостинг". Правда, там зашкаливала нагрузка процессора. Атака шла с этих же IP, подписанных ботами поисковых систем: Гугл и Яндекс. Указанны IP заблокированы в htaccess еще в январе.