Перейти к содержанию

Рекомендуемые сообщения

Други здравствуйте, 

умумукался искать ошибку, решил курнуть на форуме )

короче ситуевина такая: Виснет апач, не проходят заказы, если дернуть версию php и перезагрузить httpd поисходят чудеса, заказы прилетают кажные 20-30 минут но в течение 2 часов, потом опять зависает (

как лечить х.з. техподдержку затераризировал, толку ноль.

пациент-mirchulok.ru

новый хостинг не предлагать, уже 4-й меняю, сейчас vds на админвпс

Изменено пользователем Rashp

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а что там по логам сервера?

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

в основном фигня, когда сервант передергиваю

 

[Mon Feb 20 17:22:01.580512 2017] [mpm_prefork:notice] [pid 28573] AH00171: Graceful restart requested, doing restart
[Mon Feb 20 17:22:01.895060 2017] [auth_digest:notice] [pid 28573] AH01757: generating secret for digest authentication ...
[Mon Feb 20 17:22:01.896048 2017] [lbmethod_heartbeat:notice] [pid 28573] AH02282: No slotmem from mod_heartmonitor
[Mon Feb 20 17:22:02.132775 2017] [mpm_prefork:notice] [pid 28573] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations
[Mon Feb 20 17:22:02.132803 2017] [core:notice] [pid 28573] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Mon Feb 20 17:22:22.994592 2017] [mpm_prefork:notice] [pid 28573] AH00171: Graceful restart requested, doing restart
[Mon Feb 20 17:22:23.161353 2017] [auth_digest:notice] [pid 28573] AH01757: generating secret for digest authentication ...
[Mon Feb 20 17:22:23.163255 2017] [lbmethod_heartbeat:notice] [pid 28573] AH02282: No slotmem from mod_heartmonitor
[Mon Feb 20 17:22:23.239896 2017] [mpm_prefork:notice] [pid 28573] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations
[Mon Feb 20 17:22:23.239916 2017] [core:notice] [pid 28573] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Mon Feb 20 17:22:47.780597 2017] [mpm_prefork:notice] [pid 28573] AH00170: caught SIGWINCH, shutting down gracefully
[Mon Feb 20 17:22:48.898034 2017] [suexec:notice] [pid 9803] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Feb 20 17:22:48.927188 2017] [auth_digest:notice] [pid 9803] AH01757: generating secret for digest authentication ...
[Mon Feb 20 17:22:48.927813 2017] [lbmethod_heartbeat:notice] [pid 9803] AH02282: No slotmem from mod_heartmonitor
[Mon Feb 20 17:22:48.967815 2017] [mpm_prefork:notice] [pid 9803] AH00163: Apache/2.4.6 (CentOS) mpm-itk/2.4.7-01 OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations
[Mon Feb 20 17:22:48.967843 2017] [core:notice] [pid 9803] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Mon Feb 20 17:25:59.163502 2017] [mpm_prefork:error] [pid 9803] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если у вас VDS, лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее.

 

А проблема, вероятно, в этом:

 server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

У вас закончились свободные воркеры. Если на сервере достаточно оперативки, можно увеличить их количество в конфиге.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

на ДДОСинг проверяли?

либо какая то кривая рекурсия

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
47 минут назад, Dotrox сказал:

Если у вас VDS, лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее.

 

А проблема, вероятно, в этом:


 server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

У вас закончились свободные воркеры. Если на сервере достаточно оперативки, можно увеличить их количество в конфиге.

 

Попробую, оперативки там 4 гб, должно по идее хватить, спасиб за наводку.

 

На php-fpm сам не перееду к сожалению, для меня сложновато.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 минуты назад, Rashp сказал:

На php-fpm сам не перееду к сожалению, для меня сложновато.

 

Нужно просто установить php-fpm и поправить конфиги nginx, чтоб он проксировал php запросы на сокет php-fpm, а не на Апач. Ну, и содержимое .htaccess перенести в конфиг nginx (конечно, в формате nginx, а не Апача).

Ну, или можете обратиться ко мне :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я правильно понимаю, что надо править MaxRequestWorkers в mpm_prefork.conf?

у меня сейчас там такие значения:

<IfModule prefork.c>
StartServers       1
MinSpareServers    1
MaxSpareServers    5
ServerLimit       10
MaxClients        10
MaxRequestsPerChild  4000
</IfModule>

 

18 минут назад, Dotrox сказал:

 

Нужно просто установить php-fpm и поправить конфиги nginx, чтоб он проксировал php запросы на сокет php-fpm, а не на Апач. Ну, и содержимое .htaccess перенести в конфиг nginx (конечно, в формате nginx, а не Апача).

Ну, или можете обратиться ко мне :)

 

в личку давайте перейдем по этому вопросу

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Отправил в личку

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А какая у вас версия Апача?

Параметр MaxRequestWorkers появился в 2.4, а у вас, похоже, конфиг от более старой версии, где оно называлось MaxClients.

 

Если у вас 2.4, приведите этот блок к такому виду:

<IfModule mpm_prefork_module>
  StartServers                    1
  MinSpareServers                 1
  MaxSpareServers                 10
  MaxRequestWorkers               100
  ServerLimit                     100
  MaxConnectionsPerChild          300
</IfModule>

А дальше смотрите появляется ли ошибка и сколько памяти свободно. Если ошибка будет повторяться, но есть свободная память, увеличивайте значения MaxRequestWorkers и ServerLimit на равные числа пока либо не исчезнет ошибка, либо не закончится память (и тогда только переход на php-fpm, воркеры которого потребляют памяти до 10 раз меньше, чем у Апача).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В 20.02.2017 в 18:32, Dotrox сказал:

лучше вообще откажитесь от Апача - php-fpm будет работать намного быстрее.

 

чем можно подтвердить данную концепцию? желательно в цифрах. И при конкретных входных данных, учитывая количество просмотров, одновременных подключений и т. п. Любопытно было бы глянуть на авторитетные исследования по этому поводу.  В сравнении, разумеется, разных вариантов при разных входных параметрах.

С какого момента (по загруженности) начинает ощущаться разница в концепциях?  Минусы?

Изменено пользователем sitecreator

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
23 минуты назад, sitecreator сказал:

чем можно подтвердить данную концепцию? желательно в цифрах.

 

Видимо, вы никогда с php-fpm не работали, иначе вопросов бы не возникало.

Но вот вам цифры: https://www.cloudways.com/blog/php-fpm-on-cloud/

 

И маленький экскурс в историю: php-fpm был разработан в Badoo для их хайлоада, то есть его изначальной задачей была именно производительность.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Практического интереса ради переключил один проект на nginx+php-fpm.  Товаров, в принципе, не очень то и много пока, всего примерно 16000. Но ожидается нагрузка весной, товар сезонный.

Несколько неудобно, что нельзя использовать привычные .htaccess.  И все, что связано с rewrite (для того же ЧПУ) нужно прописывать отдельно в .config для определенного хоста, да и правила записи rewrite для nginx отличны от Апаче.

 

Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен?

И насколько быстрее работает связка nginx+php-fpm чем Apache MPM-ITK+php как модуль? или быстрее связки Apache MPM-ITK +php как модуль + nginx?

 

Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS?  Понятное дело, что на шеаред хост-площадках это неактуально потому, что выбор невозможен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, sitecreator сказал:

Можно ли принять за правило рекомендовать всегда для Опенкарт связку nginx+php-fpm в случае VPS/VDS?

 

Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю. У первого, переехавшего на такую связку клиента, уже где-то года полтора прошло с момента переезда и никаких проблем за это время не возникало.

 

 

1 час назад, sitecreator сказал:

Несколько неудобно, что нельзя использовать привычные .htaccess.

Это с непривычки. На самом деле, конфиги nginx значительно удобней и логичней.

 

 

1 час назад, sitecreator сказал:

Возникает вопрос: а нужен ли тогда Апаче? Для чего собственно если nginx+php-fpm так прекрасен?

Не нужен. По крайней мере для ОК и любого другого php сайта. Не буду утверждать, что его существование вообще бессмысленно, думаю, есть варианты, где без него не обойтись, но не в случае php. Как я уже сказал, я на VDS в принципе Апач никогда не ставлю.

Для php есть nginx+php-fpm, для Python - nginx+uWSGI.

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Интересно, какой приоритет (по производительности) в выборе:

1) nginx+php-fpm

2) апаче + php (модуль) + nginx

3) апаче + php (CGI) + nginx

 

В плане производительности 1-й наиболее производителен, последний - наименее.  Верно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
47 минут назад, Dotrox сказал:

Ну, лично я когда кого-то перевожу с шареда на VDS, то это исключительно nginx+php-fpm, а Апач на сервер принципиально не ставлю.

 

Мне вот такой вариант (с вашей подачи)  сразу понравился.  думаю, что от Апаче тоже откажусь и в будущих проектах. Он громоздкий, кроме авторизации средствами Апаче полезным вроде бы и не выделяется, а для Опенкарт такая авторизация неактуальна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, sitecreator сказал:

В плане производительности 1-й наиболее производителен, последний - наименее.  Верно?

 

На счёт первого - да, а вот следующие два в каком порядке расставить я затрудняюсь ответить. Но, вроде, mod_php таки должен быть быстрее в виду большего родства с самим Апачем (в смысле, что интерпретатор запускается в процессе самого Апача).

 

И кстати, логичнее nginx в различных связках всегда ставить на первое место, поскольку именно он встречает запросы на входе.

 

1 час назад, sitecreator сказал:

кроме авторизации средствами Апаче полезным вроде бы и не выделяется

 

Если речь идёт о запароливании пути средствами сервера, то nginx и это умеет: http://nginx.org/ru/docs/http/ngx_http_auth_basic_module.html

 

Вообще, за несколько лет использования nginx  в качестве полной замены Апача я ещё не сталкивался с функциями, которые были бы только у Апача, но не у nginx.

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php? Это в принципе возможно для Опенкарт?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, sitecreator сказал:

Удавалось ли использовать кеширование средствами nginx для контента, генерируемого за счет php?

 

Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет.

 

 

1 час назад, sitecreator сказал:

Это в принципе возможно для Опенкарт?

 

Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение.

 

Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Потратил несколько дней на серьезное изучение nginx + php-fpm.

Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать.  В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm )  нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm.

 

Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль)  поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено.  Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль").  Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на  данный вопрос.

 

Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С

В Опенкарт поступаем аналогично.

В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку:

 

fastcgi_param   REMOTE_USER       $http_authorization;

Тогда http авторизация будет работать.

 

---------------------------------------------

Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты.  Например, при использовании файла .user.ini некоторые строки в нем игнорируются.

 

display_errors = Off

Вот это никак не работает в случае nginx+php-fpm.  Хотя в случае апаче + php (в любом варианте) работает.

memory_limit = 64M

Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает!   Более того, не работает в коде php отключение ошибок:

ini_set('display_errors', '0');

 

Также не работает в .user.ini  в случае nginx+php-fpm и это:

max_execution_time = 500

 

Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php

 

73b9ab6d87.jpg

 

cf435b1977.jpg

 

Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет

@

Вообще получил с показом ошибок пока непонятную ситуацию.

Во всех php.ini файлах display_errors  установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено.  Я не смог их отключить! php не реагирует на параметры ini файла!

 

9be8792db2.jpg

 

cf10ae2f13.jpg

 

 

Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI  и nginx. 

В случае php как модуля апаче или апаче+ php (fastCGI)  такой проблемы не возникает.

Объяснения пока не нашел.

 

Сталкивались ли с подобным?

Изменено пользователем sitecreator
  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По поводу отключения показа ошибок. из .user.ini считываются изменения не мгновенно, они кешируются на время, которое можно менять. Это мне известно. Другие директивы ведь отрабатываются, поэтому грешить на кеширование или отсутствие перезагрузки веб-сервера не стоит. К тому же ради экспериментов установил время кеширования в 1 сек для файлов .user.ini.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
4 часа назад, sitecreator сказал:

Потратил несколько дней на серьезное изучение nginx + php-fpm.

Всплыли некоторые особенности, о которых не думаешь вообще когда у вас установлен апаче + php (модуль) . Так, в частности, решения (модули) для работы по протоколу 1С CommerceML 2 без проблем (и лишних телодвижений и настроек) функционируют только в случае [nginx] + апаче + php (модуль). nginx в квадратных скобках означает, что он может быть, а может и отсутствовать.  В случае работы php в режиме CGI/FastCGI с использованием Апаче или без него ( nginx+php-fpm )  нужны дополнительные настройки, а также может понадобиться некоторое изменение файлов Опенкарт, отвечающих за связь по протоколу 1С. Мне пришлось делать изменения в файлах в дополнение к настройкам в случае nginx+php-fpm.

 

Вообще никакого описания настроек и необходимых изменений в случае если у вас не [nginx] + апаче + php (модуль)  поставщиком файлов (exchange 1c, обмен с 1С) не предусмотрено.  Та же "Большая птица", к примеру, предлагающая организацию складского и бух. учета (все по протоколу 1С) никакой документации в случае использования "нестандартного" сервера не предлагает. Но если не делать дополнительных настроек/изменений, то будет ситуация (со стороны 1С), что связь будет невозможна ("неверно указан адрес сайта" или "неверные логин/пароль").  Повторюсь, что эти сервисы складского и торгового учета (класс 365, Мой склад, Большая птица и т. д.), основанные на протоколе обмена 1С, никаких решений для "нестандартный" серверов не предлагают и даже в форуме поддержки слабо обращают внимание на  данный вопрос.

 

Решение для случая [nginx] + апаче + php (CGI/FastCGI) если работает описано здесь (для битрикса, разумеется): Не работает авторизация при обмене данными с 1С

В Опенкарт поступаем аналогично.

В случае nginx+php-fpm нужно в конфиге хоста добавить в блок обработки php строку:

 


fastcgi_param   REMOTE_USER       $http_authorization;

Тогда http авторизация будет работать.

 

---------------------------------------------

Но в случае nginx+php-fpm открылись некоторые совершенно необъяснимые пока моменты.  Например, при использовании файла .user.ini некоторые строки в нем игнорируются.

 


display_errors = Off

Вот это никак не работает в случае nginx+php-fpm.  Хотя в случае апаче + php (в любом варианте) работает.


memory_limit = 64M

Это (да и многие другие директивы) работает, а отключение вывода ошибок не работает!   Более того, не работает в коде php отключение ошибок:


ini_set('display_errors', '0');

 

Также не работает в .user.ini  в случае nginx+php-fpm и это:


max_execution_time = 500

 

Если посмотреть мануал: http://php.net/manual/ru/errorfunc.configuration.php

 

73b9ab6d87.jpg

 

cf435b1977.jpg

 

Я не смог отключить никаким образом мешающие nitice кроме одного способа: подавлением в самом коде за счет


@

Вообще получил с показом ошибок пока непонятную ситуацию.

Во всех php.ini файлах display_errors  установлен в Off (0), причем настройки делались из ispmanager или вручную, но phpinfo неумолимо показывал, что во всех файлах php.ini отображение ошибок включено.  Я не смог их отключить! php не реагирует на параметры ini файла!

 

9be8792db2.jpg

 

cf10ae2f13.jpg

 

 

Повторюсь, что такое странное поведение с некоторыми директивами характерно только в случае php как FPM/FastCGI  и nginx. 

В случае php как модуля апаче или апаче+ php (fastCGI)  такой проблемы не возникает.

Объяснения пока не нашел.

 

Сталкивались ли с подобным?

 

О да!!!!
Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера!

Я смотрю тут проФФесионалы собрались.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
13 минут назад, Yoda сказал:

Это жестяная жесть, ставить nginx+phpfpm и пытаться настроить конфиги из ISP менеджера!

 

 

Додумали?

Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager.

 

Разве из контекста не видно, что конфиги вручную правились?

 

Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того.

 

Богатый ли у вас опыт работы с nginx+phpfpm?  Поделиться советом не желаете?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
27 минут назад, sitecreator сказал:

 

 

Додумали?

Разумеется, что прописывались вручную. Через блокнотик, встроенный в ISPmanager.

 

Разве из контекста не видно, что конфиги вручную правились?

 

Просто привел для примера, что по умолчанию ispmanager, видимо, косячит иногда с конфигами. не более того.

 

Богатый ли у вас опыт работы с nginx+phpfpm?  Поделиться советом не желаете?

 

Нет не желаю. По двум причинам.
Во первых к вам и дотроксу я испытываю глубокую личную неприязнь как к проФФесионалам с большой буквы.
Во вторых по сути вопроса на 99% проектов прирост производительности настолько ничтожный, что это экономия на спичках. 
И в силу того что нативно Opencart заточен все-таки под работу в связке apache + mysql а не nginx+phpfpm + mysql, делать в такой конфигурации магазины я крайне не рекомендую никому!

А вы сейчас два героя разведете здесь демагогию и начнется волна. А мне вот так надо - а так быстрее. А нифига так не быстрее. Подобное решение уместно абсолютно на высоконагруженных проектах от 100+ одновременных сессий - не вопрос. Актуально более чем. А на средней руки магазин даже в 5 000 хостов в день - это чистой воды погоня за модой и костыли! На те самые 99% магазинов достаточно поставить nginx как проксирующую заглушку, оптимизирующую раздачу статики и забыть про все проблемы с индивидуальным конфигурированием окружения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.