Форум

Но сама возможность на вайлды у летсенкрипта уже есть

Эта проблема не из-за неверной настройки кэша, а проблема настройки кэша самой системой. И кэш этот МЕНЮ. Эта проблема тянется много лет. Я решал ее в 2 подхода, потому что у меня большой сайт и кэша тоже много и меню несколько уровней. Сначала по выработанному гайду я во всех компонентах меню добавил следующее:
"CACHE_SELECTED_ITEMS" => "N"
Это помогло лишь отчасти: в скорости забивания inodes, они ЧУТЬ медленней стали забиваться. Прошло время, я заколебался чистить их опять. Гуглил и ходил по параметрам настройки в хэлпе и нашел еще один параметр:
"MENU_CACHE_USE_USERS" => "N"
Он убирает кеширование прав, насколько я понял. После этого мои волосы стали шелковистыми, а сервер перестал неожиданно падать. Вот так у меня было: [URL=http://joxi.ru/n2YB7d7io35xZA]http://joxi.ru/n2YB7d7io35xZA[/URL]

[QUOTE]kyaroslav написал:
[QUOTE] Алексей Шафранский написал:
[QUOTE] kyaroslav написал:
Справедливо когда на одном vps один сайт. А если несколько? Есть кто это делал в такой ситуации?[/QUOTE]
kyaroslav , без разницы сколько сайтов будет на vps) Логика такая же как  Александр Суворов написал выше:

1) создаете N сайтов: mysite.ru mysite.com mysite.de mysite.net и т.д.
2) в dns прописываете ip  - сайт для каждого сайта
3) дальше работает nginx)[/QUOTE]
правильно я понимаю, если на каждый сайт отдельный ip прописан. Если один ip на весь vps(vds) то уже так не сделать?[/QUOTE]
Отчего же? nginx по имени хоста будет определять какому сайту отправлять запрос

[QUOTE]Алексей Шафранский написал:
[QUOTE] Олег Дыбкин написал:

Настраивал согласно этой инструкции -   [URL=https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2943&LESSON_PATH=3913.4776.4620.4978.2943]https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2943&LESSO...[/URL]
[/QUOTE]
Проблема решена. Изначально пошли не по той тропинке) Статья в курсе не актуальная, если пройти по шагам - агенты на кроне сломаются и не будут работать. Материал статьи подправим.[/QUOTE]
А как правильно в результате?

[QUOTE]Алексей Шафранский написал:
Владислав Голубев , да, в 7.3.2 все есть.[/QUOTE]
Интересно с 7.0 на 7.3.2 если перейти (5,5 и 7.02 mysql и php) Это сильно смертельно или лучше не шутить )

[QUOTE]red_eye написал:
Скажите, пожалуйста. Зачем при добавлении нового сайта происходит restart:
[QUOTE]RUNNING HANDLER [web : restart nginx] ******************************************
RUNNING HANDLER [web : restart httpd] ******************************************[/QUOTE]
Есть гораздо более безопасная и быстрая команда reload вместо restart.[/QUOTE]
Потому что релоад не перегружает процесс полностью, а это важно

Отличное решение, добавляется в conf-файл в /etc/nginx/bx внутри блока server - который отвечает за ваш сайт

А у вас в секции server какие server_name?

server {    listen       443;
   server_name  example.org  [URL=http://www.example.org]www.example.org[/URL];
}

Может у вас там "_" стоит? То есть обрабатываются все запросы с любого хоста?

Можно сделать отдельную секцию для вашего IP и там уводить запрос в return 444 (закрытия соединения)

server {
listen      443;
   server_name "" [URL=https://123.123.123.123/]123.123.123.123[/URL];
   return      444;
}


Почитайте документацию [URL=http://nginx.org/ru/docs/http/request_processing.html]http://nginx.org/ru/docs/http/request_processing.html[/URL]

Сделать лучше 301 редирект на тот адрес который вы считаете основным. По хорошему, у сайта не должно быть лишних зеркал, да еще и некорректных. Переадрессация в соответствующих секциях server в конфигурации nginx для http и https отдельно.

[QUOTE]Алексей Тарасов пишет:
Где-то в сети гулял скрипт, вот допилили и пользуемся, сливает базу мультисайта каждый день (точнее ночь  :) , плюс инкрементально папки все, раз в неделю полный бекап. Синхронизируем с удаленным хранилищем через rsync. Встроенный как-то тоже не прижился, т.к. на момент своих разработок его еще не было, а сейчас вроде как и ни к чему уже  :)
[/QUOTE]Где же его взять? )