Если белый, то тогда не парьтесь!
Не спасет эта сомнительная блокировка, только ухудшит показатели посещаемости!
Тоже так думаю, что шляпа это. Нереально собрать айпи "госсетей" и поддерживать их в актуальном состоянии. Если у них будет цель проверить сайт и заблокировать - они тоже не идиоты и знают что такое впн или прокси. Еще пару лет назад эти ребята с антизапрета предлагали за приличные деньги "спасать" сайты от блокировок. Но никаких гарантий что это работает ни от кого и никогда не слышал.
Ну если очень уж хочется, то следующим образом:
wget https://github.com/AntiZapret/antizapret/archive/master.zip unzip master.zip cd antizapret-master/ sed -i 's|/etc/nginx/sites-available/|/etc/nginx/fastpanel2-sites/yourdomain.com/|g' nginx.sh bash nginx.sh systemctl restart nginx
Обратите внимание, в четвёртой строке нужно заменить yourdomain.com на домен вашего сайта.
По итогу пользователи из сетей, которые в списках будут получать такое сообщение через редирект:
Глянул скрипты. Принцип работы в том, чтобы скачать себе на сервер все файлы оттуда и запустить либо apache.sh либо nginx.sh в зависимости от того, на каком вебсервере собираетесь блочить. Но они не всегда и не на всех системах отработают корректно, ибо некоторые пути к конфигам могут отличаться на вашем сервере. Может что-то еще не совпасть. Основная суть в том, чтобы взять список сетей из https://github.com/AntiZapret/antizapret/blob/master/blacklist4.txt и каким-либо образом заблокировать доступ с этих айпи на своём сервере. Причем для nginx и для apache по разному блок устроен. Для nginx ставится редирект на какую-то заглушку, для апача скрипт добавляет в .htaccess обычный запрет 403 с этих адресов.
Не плевать. Если там 8 ядер, то может оно и так. А если минимальный VPS в 1-2 ядра и хотя бы несколько тысяч трафика в сутки - то будет ощущитимая лишняя нагрузка. Уровня сжатия в 5-6 достаточно, более не имеет никакого смысла.
И по статике, и по нагрузке будет хуже.
Дело в том, что когда апач начинает раздавать статику, его это довольно сильно нагружает, он использует при этом ощутимо больше ресурсов, чем nginx, вследствие чего он медленнее начинает обрабатывать и PHP. Когда же этим делом занимается nginx, то он делает легко, быстрее, и при любых мыслимых нагрузках, кушая при этом минимум ресурсов. Соответственно апачу становится сильно легче обрабатывать PHP, меньше вероятности что он "захлебнется" при пиковых нагрузках.
Ну аналог, не аналог, но смысла в этом особо нет. Сопоставимо, если нагрузок больших нет, но учитывая что через панельку это не настраивается, то какой смысл вебмастеру с этим заморачиваться.
Не даст. По крайней мере если использовать тот fastcgi, что переключается в настройках панельки ispmanager - он ничем не отличается там от обычного CGI, то есть для каждого скрипта запускается отдельный тормозной php-cgi процесс, который еще и opcache не подхватывает. Самый медленный, прожорливый и низкопроизводительный режим. Если вы имели в виду apache+php-fpm - то согласен. Но такое только вручную настраивается на серверах без панели.
Самый универсальный и приемлемый по производительности и скорости вариант - это nginx+апач в режиме модуля PHP, что, как я понимаю у ТС и используется. Производительнее только nginx+php-fpm, но там теряем в универсальности и получаем лишнюю настройку.
Хотя, если сайты на wordpress без увешивания плагинами, рисующими простыни в htaccess, то ничего не теряем )
Здравствуйте. Подскажите, почему показывает сервер, что всего есть места на диске 1740038836, при этом занято 1667920332 и при этом свободно 0 (ноль)? Может нужно что-то перезапустить на сервере, чтобы информация обновилась? Подскажите пожалуйста.
Всего Занято Свободно
/dev/mapper/vg0-home 1740038836 1667920332 0 100% /home
Сервер перезагружал.
ОС Centos
Всё верно вы поняли - такое происходит когда вы удалили файл, который пишется софтом или системой. Он будет отображать что вроде как есть свободные байты, но по факту эти блоки в статусе busy, пока вы не перезапустите какой-нибудь сервис. Чаще всего при занятом месте чистят логи, а логи как раз из разряда тех файлов, которые "не отпускает" пока не перезапустишь софт, который их пишет. Чтобы чистить большие логи и сразу высвобождалось место без перезапуска софта нужно делать примерно такое:
cat /dev/null > /var/log/apache/site.big-access.log
В таком случае у вас место освободится сразу же, даже если это файлы используемые софтом.
А еще, для аудита диска на предмет занятости хламом и большими файлами рекомендую замечательную утилитку ncdu ;)
Вообще, редко у каких хостеров скорость ответа сервера (TTFB сайта) упирается в железо, по крайней мере на KVM.
При использовании KVM в 90% оптимизировав настройки софта на сервере - выжмешь из него всё, что умеет это железо. Хоть облачный, хоть не облачный. В случае с OVZ такое редкость. В случае с KVM - всё наоборот.
А если там оверселл OVZ, еще и на старом железе, то никакие настройки не спасают (что чаще и бывает). Еще сложнее, когда сама CMS тугая, тяжелые шаблоны, плагины, и т д, когда сам PHP-код медленно исполняется. Там может как-то помочь лишь кэширование всего на свете, на уровне nginx, но это годится только для простых сайтов. Ну и при его использовании там какое угодно железо и какие угодно диски - всё будет "летать", если из кэша)
Доброго времени суток, господа! Задачи системного администрирования серверов решаю по-прежнему, а со временем и нарабатываемым опытом лишь всё качественнее и быстрее. Так что всегда рад решить ваши проблемы с долгим временем ответа сервера, чрезмерной нагрузкой и прочими вещами. Напомню, что в моём блоге есть отличный гайд по самостоятельной оптимизации серверов для любых CMS, где я поделился своим многолетним опытом "от и до"!
Кроме того, у меня есть и новости. Я написал статью о том, как выбирать хорошие хостинги по отзывам и рейтингам . Не секрет, что рейтинговые сервисы не всегда предоставляют актуальную и объективную информацию о хостерах. Поэтому делюсь своим опытом как выбираю и быстренько "пробиваю" хостинги лично я, используя searchengines и прочие вебмастерские площадки, где собран действительно личный опыт вебмастеров. Используя этот способ вы всегда найдете самую правдивую и объективную инфу о том или ином хостинге!
И еще я запустил канал в телеграм, где делюсь различными "фишками" выбора хостингов и о том как их использовать. Хостинг Эксперт - мой независимый авторский канал о хостерах, серверах, об их подборе и грамотном использовании.
И снова здравствуйте! Последнее время с серчем творится что-то странное, поэтому редко захожу сюда. Извиняюсь перед теми, чьи сообщения упустил в личке. Обращаться лучше через сайт vpsadm.ru - там есть все актуальные контакты. В телеграм всегда онлайн на связи - @vpsadm_ru
Ну и конечно напоминаю, что всё так же оказываю услуги системного администрирования серверов Linux. Специализируюсь на оптимизации под нагрузку и скорость, но и многие другие работы мне по силам!
Ну а для тех, кто хочет и любит разбираться со своими серверами самостоятельно - есть небольшой бонус от меня:
https://vpsadm.ru/bystryi-perenos-saytov-sposobyi/ - статья о том, как удобно легко и быстро переносить сайты в любых количествах и объемах с одного сервера на другой.
Всегда рад помочь, господа!
Ничего. Просто информация о статусе некоторых актуальных параметров и фич.
