Error unable to obtain session lock перевод

Ошибка Bitrix — Unable to get session lock within 60 seconds Столкнулся с ошибкой в Bitrix, связанной с сессиями. Особенностью данной установки, осложнившей решение проблемы, было то, что сессии хранились в Memcache. В общем случае есть очень много причин, по которым может возникать подобная ошибка. Расскажу о тех, что мне известны. В моем случае […]

Содержание

  1. Ошибка Bitrix — Unable to get session lock within 60 seconds
  2. Hardware and performance
  3. Moodle on cloud with Redis Cache: Unable to obtain session lock
  4. Moodle on cloud with Redis Cache: Unable to obtain session lock
  5. Настройка балансировки SQL-запросов через ProxySQL для Bitrix
  6. Ахтунг!
  7. Теория
  8. Архитектура
  9. RUNTIME
  10. MEMORY (main)
  11. CONFIG FILE
  12. Запуск
  13. Установка
  14. Конфигурирование
  15. Подготовка
  16. Добавление backend-серверов
  17. Настройка мониторинга
  18. Настройка таблицы для распределения запросов
  19. Настройка пользователей
  20. Настройка правил запросов
  21. Возникающие ошибки:

Ошибка Bitrix — Unable to get session lock within 60 seconds

Столкнулся с ошибкой в Bitrix, связанной с сессиями. Особенностью данной установки, осложнившей решение проблемы, было то, что сессии хранились в Memcache. В общем случае есть очень много причин, по которым может возникать подобная ошибка. Расскажу о тех, что мне известны.

В моем случае ошибка выглядела следующим образом:

Ошибка эта с большой долей вероятности будет возникать на очень долгих запросах. Логично начать решение проблемы именно с этой стороны и по возможности упростить или ускорить запрос. Но может оказаться так, что нет возможности ускорить запрос, так как его выполняет какой-то готовый модуль или его выполнение связано с какими-то сторонними зависимостями и приходится ждать ответа.

Решение ошибки Unable to get session lock within 60 seconds будет зависеть от того, где у вас хранятся сессии. Если в базе данных, то нужно увеличить таймаут ожидания ответа от базы данных. Для этого надо добавить в параметры Mysql сервера следующую настройку:

Не забудьте перезапустить mysql сервер после этого. Если не помогло, то проверьте настройки php. Там тоже можно упереться в ограничение таймаутов в минуту и больше. Увеличьте таймауты в следующих параметрах:

Далее проверяем настройки nginx и таймауты ожидания ответа от backend:

Если ошибка с session lock не проходит, то двигаемся дальше. Если у вас сессии хранятся в memcache, то вас ждёт сюрприз. Параметр lockWait для memcache задан жестко в коде bitrix и так просто вы его не найдёте. Подсказываю сразу, где искать:

Меняем на 600 секунд:

Если уж и это не поможет, то разбирайтесь с самим запросом. 10 минут ждать его завершения слишком долго. Увеличивать таймауты еще больше не имеет смысла.

Источник

Hardware and performance

Moodle on cloud with Redis Cache: Unable to obtain session lock

Moodle on cloud with Redis Cache: Unable to obtain session lock

Hello everyone, in various pages of my moodle, both reserved for the administrator and for public access, I get:
error/Unable to obtain session lock

My setup is as follows:
Moodle 3.9.4+ 20210211
PHP 7.2.20
Apache/2.4.6(Server MPM: prefork)
MySQL 5.7.28 (on cluster)
Redis server (for application cache) v=6.0.9
Redis server (for session cache) v=6.2.0
O.S. CentOS Linux release 7.5
shared Network File System for moodle files and moodledata no SSD

(Some configurations, as prefork, are bound by company policies)

I have a large DB (105 GB) and about 60000 users with over 2600 courses
4 virtual machine on cloud behind a V.I.P. and a load balancer, every v.m. with 12 vCPU (Intel Xeon CPU X5650 2.67GHz) and 9 GB of RAM
1 v.m. with Redis for application cache (8 vCPU (Intel Xeon CPU X5650 2.67GHz) and 8 GB of RAM)
1 v.m. with Redis for session cache (8 vCPU (Intel Xeon CPU X5650 2.67GHz) and 8 GB of RAM)
1 v.m. only for crontab every minutes (12 vCPU (Intel Xeon CPU X5650 2.67GHz) and 9 GB of RAM)
1 v.m. for MySQL DB as a Service (4 Cpu (3.2 GHz), 8 Gb ram)

Some examples on log files:
Cannot obtain session lock for sid: cphrrvj5kvc5ou11ueptoabi8p within 120 seconds. It is likely another page ([pid 4708] /course/view.php?id=123794) has a long session lock, or the session lock was never released.
Cannot obtain session lock for sid: jugh67eg4591fe4l87ngnptf2l within 120 seconds. It is likely another page ([pid 9690] /mod/lesson/view.php?id=92443) has a long session lock, or the session lock was never released., referer: https://xxxxxxxx/course/view.php?id=123456
Cannot obtain session lock for sid: d6ekd6a8mbkmj7mgpni5aq12uk, referer: https://xxxxxxxx/mod/quiz/review.php?attempt=1199680&cmid=101507
Cannot obtain session lock for sid: e7ijkt4dthsmclf4mkaromncj7 within 120 seconds. It is likely another page ([pid 1544] /admin/category.php?category=users) has a long session lock, or the session lock was never released., referer: https://xxxxxxxx/
Cannot obtain session lock for sid: 7cl4kh6e9dpmoniro6peign6oc, referer: https://xxxxxxxx/mod/scorm/player.php
Cannot obtain session lock for sid: 0ab2kt5vk0h7tr3ns296cg2ngc within 120 seconds. It is likely another page ([pid 30065] /course/index.php?categoryid=123) has a long session lock, or the session lock was never released., referer: https://xxxxxxxx/course/index.php?categoryid=123
Cannot obtain session lock for sid: lnb5hfjfd8affontfk8n9300oj within 120 seconds. It is likely another page ([pid 20917] /admin/category.php?category=modules) has a long session lock, or the session lock was never released., referer: https://xxxxxxxx/
Cannot obtain session lock for sid: emv3hrqa0b5grtu1m64jfu3ffa within 120 seconds. It is likely another page ([pid 6231] /course/view.php?id=123123) has a long session lock, or the session lock was never released., referer: https://xxxxxxxx/login/index.php
Cannot obtain session lock for sid: 9oq3tadrb5lmgp2jj709suun24 within 120 seconds. It is likely another page ([pid 11245] /report/progress/index.php?course=123321&silast=R) has a long session lock, or the session lock was never released., referer: https://xxxxxxxx/course/index.php?categoryid=123
Cannot obtain session lock for sid: eg549ic50eikmc2di4l52c2g7i within 120 seconds. It is likely another page ([pid 14670] /mod/customcert/my_certificates.php?userid=xxx&certificateid=xxx&downloadcert=1) has a long session lock, or the session lock was never released., referer: https://xxxxxxxx/mod/customcert/my_certificates.php?userid=xxx

Our config.php is as follows:
$CFG->enable_read_only_sessions = true;
$CFG->preventfilelocking = true;
$CFG->session_handler_class = ‘coresessionredis’;
$CFG->session_redis_host = ‘xx.xxx.xx.x’;
$CFG->session_redis_port = 6379; // Optional.
$CFG->session_redis_database = 0; // Optional, default is db 0.
$CFG->session_redis_auth = ‘xyz’; // Optional, default is don’t set one.
$CFG->session_redis_prefix = »; // Optional, default is don’t set one.
$CFG->session_redis_acquire_lock_timeout = 120;
$CFG->session_redis_lock_expire = 7200;
$CFG->session_redis_lock_retry = 10;
$CFG->session_redis_acquire_lock_retry = 10;

$CFG->local_redislock_redis_server = ‘xx.xxx.xx.x’;
$CFG->lock_factory = ‘\local_redislock\lock\redis_lock_factory’;
$CFG->local_redislock_auth = »;

On /etc/httpd/conf.d/php.conf
php_value session.save_handler «redis»
php_value session.save_path «tcp://xx.xxx.xx.x:6379»

On /etc/php.ini
session.save_handler = redis
session.save_path = «tcp://xx.xxx.xx.x:6379»

On /etc/httpd/config_vhosts/www.xxxxxxxx_443/php.conf
php_admin_value session.save_path tcp://xx.xxx.xx.x:6379

On /etc/redis.conf
‘appendonly yes’
‘appendfsync everysec’

Anyone have any ideas or suggestions to overcome the problem? Thanks in advance, have a nice day.

Источник

Настройка балансировки SQL-запросов через ProxySQL для Bitrix

Исходная проблема, из-за которой я пришёл к ProxySQL, состояла в том, что на одном из проектов, где используется старый Bitrix (установлен на RHEL 6), модуль “веб-кластер” с багами. Через него была настроена репликация Master-Slave, и периодически слейвы переставали видеться через модуль и все запросы шли на master-базу, тем самым загружая основной сервер с БД, что приводило к диким cpu iowait и как следствие – к недоступности порталов проекта. В силу того, что обновить кастомный битрикс возможности нет, как и времени на допиливание разработчиками модуля для устранения ошибок, было решено попробовать использовать стороннее решение для организации балансировки SQL-запросов для схемы Master-Slave.

В теории, изначально можно было бы использовать Nginx и TCP-балансировку, но в таком случае Nginx не воспринимал бы запросы SQL как таковые, т.к. он не умеет различать MySQL, а потому разделить их на те, которые адресованы для Slave, а которые для Master, нормальной возможности не было, используя Nginx.

Изучив инструменты, которые могли бы подойти для решения задачи, я остановился на ProxySQL, т.к. по отзывам и документации он самый стабильный и производительный.

Ахтунг!

То, как ниже описана примитивная реализация проксирования запросов до Master и Slave совсем не true-way, а костыли, но такой вариант тоже имеет право на существование при наличии всяческих обстоятельств.

Согласно документации, для продуктивного контура нужно использовать тонкую и более тщательную настройку проксирования запросов на основе статистики (время выполнения или частота вызова, например). Здесь же сделано всё “в лоб” с небольшой доработкой, нужно иметь это ввиду.

Возможно, для каких-то приложений нижеописанного будет достаточно и вообще за глаза, но в случае с битриксом, у меня возникали некоторые нюансы.

Теория

ProxySQL – ПО с открытым исходным кодом (GPL license) для проксирования SQL-запросов. Представляет собой высокопроизводительный инструмент, который можно применять для HA.

Поддерживает MySQL и его форки (Percona, Maria & etc).

Развитие ProxySQL обусловлено отсутствием прокси с открытым исходным кодом, которые обеспечивают высокую производительность.

Архитектура

Имеет весьма сложную, но простую в использовании систему конфигурации.

  • умеет обновлять динамически конфиги, что полезно для HA и нулевого времени простоя;
  • поддерживает возможность изменения элементов конфигурации, не требуя рестарта процесса ProxySQL;
  • позволяет производить легкий откат конфигов.

Официальная схема взаимодействия уровней (слоёв):

RUNTIME

Представляет структуры данных ProxySQL в памяти, содержит всю информацию для проксирования запросов

MEMORY (main)

Является базой данных в памяти, доступ к которой осуществляется через MySQL-клиент.

База содержит следующие таблицы:

  • mysql_servers – список внутренних серверов, к которым подключается ProxySQL;
  • mysql_users – список пользователей и их учетные данные, которые подключаются к ProxySQL и внутренним серверам;
  • mysql_query_rules – список правил запросов, которые анализируются при маршрутизации трафика;
  • global_variables – список глобальных переменных. Полезно для конфигурирования во время выполнения;
  • mysql_collations – список сопоставлений MySQL, доступных для работы с прокси. Извлекаются из клиентской библиотеки.

Представляет собой базу данных SQLite3 на диске. Располагается в $(DATADIR)/proxysql.db.

При перезапуске сервиса ProxySQL, все конфиги, которые правились в Memory, будут очищены. Поэтому очень важно сохранять все конфигурации в слой DISK, откуда уже идёт загрузка в MEMORY.

CONFIG FILE

Является классическим инструментом конфигурации.

Запуск

При обычном запуске, ProxySQL ищет свой конфигурационный файл, в котором определяется рабочая директория. Что произойдёт далее, зависит от наличия или отсутствия файла БД (DISK) в директории, которая указана в конфиге.

Если файл с БД есть, то происходит инициализация конфгируации из постоянной БД на диске, т.е. диск загружается в память и распространяется на конфигурация во время выполнения

Если файла с БД нет, то он генерится на основе конфига и загружается в MEMORY и RUNTIME.

Установка

Для установки добавить репозиторий, заменив в baseurl …/centos/$releasever на нужную цифру, в данном случае RHEL 6, т.к. иначе выдаст 404 ошибку:

Во избежание ошибки Unable to parse unknown SET query я установил версию ProxySQL version 2.0.5-37-gc8e32ee, т.к. при выполнении некоторых запросов после настройки были глюки. Тема обсуждалась тут.

Проверить, что успешно запустился:

Для управления через консольного клиента mysql нужно его установить:

И проверить, что само подключение устаналивается:

Командой ниже можно проверить список имеющихся таблиц. В данном случае это уровень абстракции MEMORY, т.е. БД в памяти.

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

  • [1] LOAD MYSQL USERS FROM MEMORY / LOAD MYSQL USERS TO RUNTIME
    • загружает пользователей MySQL из БД в памяти в структуры данных RUNTIME или наоборот
  • [2] SAVE MYSQL USERS TO MEMORY / SAVE MYSQL USERS FROM RUNTIME
    • сохраняет пользователей MySQL из RUNTIME в MEMORY
  • [3] LOAD MYSQL USERS TO MEMORY / LOAD MYSQL USERS FROM DISK
    • загружает постоянных пользователей MySQL из базы данных на диске в базу данных в памяти
  • [4] SAVE MYSQL USERS FROM MEMORY / SAVE MYSQL USERS TO DISK
    • сохраняет пользователей MySQL из базы данных в памяти в базу данных на диске
  • [5] LOAD MYSQL USERS FROM CONFIG
    • загружает из файла конфигурации пользователей в базу данных в памяти

Конфигурирование

Подготовка

На этом хватит теории и для полного понимания и закрепления пора переходить к практике. Исходные данные для понимания:

10.15.61.141 – ProxySQL & App
10.126.253.45 – SLAVE
10.126.253.46 – MASTER

Репликация в MySQL уже настроена. Перед началом хочу заметить, что лучше исключить из репликации таблицы b_sec_session, если сессии хранятся в БД, т.к. сами битриксы говорят, что это вызывает глюки при большой нагрузке.

Перед началом удобнее сразу создать двух пользователей на master и slave базах для доступа с сервера ProxySQL:

  • пользователь monitor , предварительно убедившись, что учетка monitor уже не используется для мониторинга самих слейвов. Через неё ProxySQL будет делать healthcheck:
  • пользователя, через которого подключается приложение к БД. В данном случае, т.к. ProxySQL находится на веб-ноде, где и само приложение, пользователь app_user уже должен быть с нужными правами:

И ещё важный момент. ProxySQL в дальнейшем должен понимать, в какую группу отнести сервера: для чтения или для записи. Изначально я подумал, что это назначается вручную, но это была ошибка. ProxySQL, используя учётку monitoring, подключается к backend и смотрит значение переменной read_only в самом MySQL. Если значение 1, то запись в БД могут вносить только пользователи с привилегиями SUPER. Таким образом, можно быть уверенным, что на слейв придут запросы на изменение только со стороны мастера (если нет иных юзеров с правами SUPER). Этакий best practice. Поэтому для слейва нужно изменить значение этой переменной глобально и потом добавить его в конфиг:

Добавление backend-серверов

Далее нужно залогиниться в консоль управления ProxySQL и добавить backend-сервера БД в нужный hostgroup:

Да, здесь не опечатка, изначально и мастер и слейв сервера добавляются с одним hostgroup_id. Можно выбрать следующие поля (остальные пока не интересуют) и проверить:

Настройка мониторинга

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

Чтобы эти значения подгрузились, нужно внести их в рантайм и на диск:

Теперь если выполнить команду ниже, можно увидеть, что ProxySQL успешно “пингует” бэкенды и в поле connect_error значение NULL – значит всё ок:

Настройка таблицы для распределения запросов

Теперь нужно поработать с этой таблицей, которая пока пустая:

С её помощью, перечисленные в ней hostgroups могут быть настроены для для направления запросов до мастера или до слейва, как раз-таки на основе значения read_only.

В строке выше была добавлена запись с writer_hostgroup (10) и reader_hostgroup (20). В последней пока нет узлов – они туда будут помещены автоматически (благодаря проверке read_only).

Если у сервера read_only = 0, он будет перемещен в группу хостов 10, т.к. это Master
Если у сервера read_only = 1, он будет перемещен в группу хостов 20, т.к. это Slave

И для применения этого осталось выполнить загрузку в рантайм:

Теперь если выполнить команду ниже, видно, что в таблице сменился hostgroup_id на нужный:

Для проверки, что всё сохранилось и загружается, я делал рестарт сервиса ProxySQL и смотрел, не изменились ли записи в таблицах. Если нет, то всё ок, можно настраивать далее.

Настройка пользователей

Осталось добавить пользователя app_user, который будет подключаться к прокси, а тот уже, в свою очередь, обращаться в нужную базу.

Стоит обратить внимание, что пользователю указывается default_hostgroup – группа, в которой мастер сервер.

Проверка, что пользователь добавлен:

И проверить, что можно подключиться (консольным клиентом с сервера приложений):

А также последняя проверка ещё раз, что ProxySQL может конектиться к бэку:

На этом всё готово и можно переходить к самой сложной и важной части – настройки проксирования запросов.

Настройка правил запросов

Осталось настроить таблицу, в которой содержатся правила, на основе которых запросы будут отправляться в ту или иную группу:

P.S. В оф. документации не указан пользователь (поле username) при наполнении таблицы mysql_query_rules. Без этого поля (без добавления оно будет NULL) у меня возникали непонятные ошибки и глюки.

Проверка, что по созданным правилам запросов выше есть хиты, т.е. всё работает:

Теперь всё минимально настроено и в настройках приложения можно переключаться на инстанс ProxySQL, который слушает локально на том же сервере, где и само приложение на порту 6033 – 127.0.0.1:6033

После открытия портала, побегав по страницам, можно выполнить запрос и увидеть, что поле Queries растёт в нужной hostgroup, а значит всё ок:

В общем и целом на этом настройка закончена. В админке битрикса лучше заранее перед настройкой ProxySQL выпилить старые настройки слейвов в модуле “Веб-кластер”, а также перезапустить сервис кеширования (memcached в моём случае), если таковой используется.

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

Возникающие ошибки:

В процессе настройки приложение себя вело странным образом, выдавая те или иные ошибки. При решении всегда смотреть в /var/lib/proxysql/proxysql.log

  • Unable to get session lock within 60 seconds (в браузере)
  • ERROR 2013 (HY000): Lost connection to MySQL server during query (в proxysql.log)

Данные ошибки были связаны с некорректными таймаутами в настройках серверов MySQL, на мастере и слейве в my.cnf:

wait_timeout – таймаут ожидания необходим, чтобы защищать приложением в том случае, когда клиенты ничего не делают, кроме как поглощают соединение. По истечении 600 сек бездействующих клиентов отключает по таймауту;

interactive_timeout – используется только для соединений с интерактивными клиентами, такими как клиенты MySQL из командной строки, с этим вроде как понятно. Обычно значение устанавливается как и wait_timeout , но в отдельных случаях может быть изменено.

net_read_timeout – количество секунд ожидания для получения дополнительных данных из соединения перед прекращением чтения. Аналогично и для клиентов, ведущих запись.

connection_timeout – сколько ждать ответа сервера перед тем, как выдать ошибку о том, что сервер не отвечает. Именно с данным параметром, значение которого увеличил с 30 до 600, ошибка Unable to get session lock within 60 seconds перестала появляться.

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

Источник

Источник


Долгая загрузка главной станицы (index.php) и долгий вход в систему

  • ◄ Перенос портативной версии
  • Ошибка при импорте тестов в формате Gift ►

Здравствуйте, проблема появилась следующая, последнее время главная страница и домашняя страница стали грузиться крайне медленно от 30 секунд до 2 минут, изначально подозревал что все из-за изображений, но после их сжатия проблема никуда не ушла, так же начала появляться ошибка «error/Unable to obtain session lock»
 

Железо на сервере следующее:
CPU платформа Intel Ice Lake на 8 ядер с 100% гарантией использования
RAM 32 ГБ
ОС ubuntu 18.04 
Веб-сервер используется nginx(v1.14)+php7.4-fpm
Как показать phpinfo не имею представления, так как страница большая

На данный момент в логах никаких ошибок не отображается.
по htop железо не перегружно 

Хотелось бы узнать как можно исправить ошибки с долгим заходом на сайт и периодическим вылезанием ошибки «error/Unable to obtain session lock».

А почему третье ядро на 100% загружено и load average больше 1 ?

load average больше 1, почему так сказать затрудняюсь, если есть способ проверить, не могли бы подсказать
третье ядро загруженно на 100% потому что сработал скрипт аннотирования в пдф

load average 1.57 за 15 минут должен означать высокую загрузку. У вас по трем значениям она стабильно высокая. У нас на сервере это значение меньше 1.
Попробуйте сбросить большую картинку в корень и по прямой ссылке ее скачать и посмотреть скорость. Потом большую статичную страничку, потом страницу с внешними ссылками. Если на этом этапе медленно, проблема с сетевым стеком. Тут что угодно может быть, плохой патчкорд, порт коммутатора, медленный dns если тема из интернета скрипты тянет, маршруты, фаервол часть внешних ссылок блокирует.

LA 1.5 Для 8 ядер это значит, что 6.5 ядер простаивает. Проблемы начнуться когда LA будет > 8
Про ошибку «error/Unable to obtain session lock» : такое сообщение есть только в случае использования redis.
Если у вас 1 сервер с moodle, то redis вам нафиг не нужен.

>> Проблемы начнуться когда LA будет > 8

Это не проблемы, у меня на 4-х ядерном E3-1225V2 LA было больше 35 для 1-5-15 улыбаюсь Даже не перегружал, просто юзеры «отваливались» из-за MySQL. А вот незачем по >190 человек одновременно тестироваться, я предупреждал, что предел — 150 )))

Для Dmitryii Gusev:  я не вижу, чтобы картинки были оптимизированы.

При размере страницы 26.8 MB, картинки весят 23.6 MB, на скачивание контента уходит более 28 сек.

ris2

Откройте инструменты разработчика в браузере, перейдите на вкладку «Сеть» и проанализируйте.

После проверки главной страницы после авторизации выдало вот такое.

Из-за чего может так долго грузиться страница, тут уже дело не в изображениях насколько я вижу.
В добавок после первого входа и загрузки потом уже все загружается корректно .

>> потом уже все загружается корректно
Потому что контент загружается с кеша — диска и памяти. Нужно кеш отключать и тестировать.

>>тут уже дело не в изображениях насколько я вижу

Плохо смотрите, хотя страница уже быстрее грузится — за 5.26 сек. Отключите и очистите кеш браузера, перезагрузите страницу, отсортируйте по времени загрузки и увидите, что первые позиции занимают как раз изображения, первое из которых весит 9.2 МВ. Вы используете изображение размером 3358х1458px для карточки курса 348х151px. Это, по вашему, нормально?

ris2

Для карточки курса достаточно такого:

maintenance 25.4 КВ

Если не считать изображения которое весит 9мб, с отлюченным кешем

Самое долгое что грузит при первом входе это сама страница.

Почему может быть именно так?

Вы для начала оптимизируйте ВСЕ изображения, потом проверяйте.
Можно использовать сайт https://gtmetrix.com, чтобы исключить проблемы на вашей стороне, потому что у меня в разных браузерах ваш сайт грузится в пределах 4 сек (уже)

На данный момент у меня имеется проблема с другой странице, ту на которую вы заходите грузится вполне адекватно, но вот страница с изображениями всех курсов что появляется после входа, она грузится крайне долго

я оптимизировал все изображения, но проблема осталась

Как мне безопасно для себя отказаться от redis?

А где взять настройки по умолчанию? Из файла conf.php?

  • ◄ Перенос портативной версии
  • Ошибка при импорте тестов в формате Gift ►
Источник


Проблема с дублированием тестов

  • ◄ Удаление ненужных курсов
  • Не загружаются видеолекции ►

Проблема с дублированием тестов

Number of replies: 2

Здравствуйте. 

Последнее время при попытке дублировать тест со случайными вопросами moodle  зависает и в данном браузере больше не открывается.

Пишет ошибку error/Unable to obtain session lock.

Тест в результате в 99% случаев не дублируется.

Это связано со слишком большой базой тестов?

курс Физическая химия Булидоровой Г.В.

In reply to Булидорова Галина Викторовна

Re: Проблема с дублированием тестов

Сейчас, почищу, генерируемые вопросы при каждом копировании удваиваются в количестве, сейчас их 15 млн.
Автоматически система их чистит, но когда делается много копирований курса, не успевает.

In reply to Богомолов Владислав Афанасьевич

Re: Проблема с дублированием тестов

  • ◄ Удаление ненужных курсов
  • Не загружаются видеолекции ►
Источник

На одном сервере часто работают сайты использующие базы данных таблицы которых имеют различный тип: MyISAM и InnoDB. Таблицы InnoDB гораздо более эффективны с точки зрения оптимизации приложений, но работать с ними на уровне сервера баз данных сложнее. В частности, восстановление таблиц при их повреждении является довольно трудозатратной процедурой.

Лог всех данных касающихся работы MySQL пишется в один файл, в нем иногда можно видеть записи следующего типа:

InnoDB: Unable to lock /path/to/ibdata1, error: 11

InnoDB: Check that you not already have another mysqld process

InnoDB: using the same InnoDB data or log files.

Часто обозначенные выше ошибки можно увидеть в логе когда сервер баз данных не запускается — часто после перезагрузки или сбоя питания.

Из записи Check that you not already have another mysqld process явно следует, что, вероятно, на сервере по какой-то причине запущены или пытаются запуститься 2 процесса MySQL.

Проверяем так ли это

ps aux | grep mysql

Если обнаружен  какой-либо процесс можно отледить его используя strace или завершить стандартным способом или через kill.

Ошибка InnoDB: Unable to lock /path/to/ibdata1, error: 11 обычно соседствует с первой — ее причина в невреных правах на некоторые InnoDB таблицы в /var/lib/mysql или другом каталоге являющемся docdir для сервера баз данных

Исправить ошибку можно выполнив несколько простых команд.

Останавливаем MySQL — часто он уже остановлен и не запускается.

/etc/init.d/mysql stop

Перемещаем файл ibdata1, в котором хранятся все данные и индексы InnoDB в сторонний каталог делая бэкап

mv /var/lib/mysql/ibdata1 /var/lib/mysql/ibdata1.bak

Копируем файл обратно восстанавливая права.

cp -a /var/lib/mysql/ibdata1.bak /var/lib/mysql/ibdata1

Запускаем mysql:

/etc/init.d/mysql start

Также скорректировать права на таблицы можно вручную перейдя в /var/lib/mysql и выполнив chown mysql: на все базы данных и таблицы, для которых установлен другой пользователь (часто это root, такое случается когда разработчики редактируют таблицы от имени root). Таблицы с некорректными правами могут успешно обрабатываться, проблемы обычно дают о себе знать после перезапуска MySQL.

MySQL после корректировки прав должен корректно запуститься, также при этом необходимо проверить логи на предмет поврежденных таблиц, при их наличии — восстановить.

Источник
 

Пользователь 223662

Заглянувший

Сообщений: 27
Баллов: 1
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 30.10.2013

#1

0

25.12.2013 18:17:00

Приветствую. После восстановления сайта с резервной копии, сайт стал на порядок медленнее работать и периодично выдавать такую ошибку:

Код 
[ErrorException] E_USER_ERROR
Unable to get session lock within 60 seconds. (0)
/var/www/bitrix/bitrix/modules/security/classes/general/session.php:71
#0: trigger_error("Unable to get s...hin 60 seconds." (45), 256)
   /var/www/bitrix/bitrix/modules/security/classes/general/session.php:71
#1: CSecuritySession::triggerFatalError("Unable to get s...hin 60 seconds." (45))
   /var/www/bitrix/bitrix/modules/security/classes/general/session_db.php:42
#2: CSecuritySessionDB::read("lvavp8lff3dkjc1gqq1oco6sf0")
   
#3: session_start()
   /var/www/bitrix/bitrix/modules/main/include.php:294
#4: require_once("/var/www/bitrix...ain/include.php" (47))
   /var/www/bitrix/bitrix/modules/main/include/prolog_admin_before.php:18
#5: require_once("/var/www/bitrix...dmin_before.php" (67))
   /var/www/bitrix/bitrix/modules/main/admin/cache.php:11
#6: require_once("/var/www/bitrix...admin/cache.php" (51))
   /var/www/bitrix/bitrix/admin/cache.php:1

Время загрузки сайта на локальной машине достигает минуты. Бизнес 14.0.6.
Прошу скорее помочь с решением проблемы.
 

Пользователь 223662

Заглянувший

Сообщений: 27
Баллов: 1
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 30.10.2013

#2

0

26.12.2013 10:03:04

/var/www/bitrix/bitrix/modules/security/classes/general/sess­ion.php:71

Код 
    class CSecuritySession

    /**
    * @param string $pMessage
    */
   public static function triggerFatalError($pMessage = "")
   {
      CHTTP::SetStatus("500 Internal Server Error");
      trigger_error($pMessage, E_USER_ERROR); //// <===71
      die();
   }

/var/www/bitrix/bitrix/modules/security/classes/general/sess­ion_db.php:42

Код 
 class CSecuritySessionDB

  /**
   * @param string $id - session id, must be valid hash
   * @return string
   */
  public static function read($id)
  {
    if(!self::isValidId($id))
      return "";

    if(!CSecurityDB::Lock($id, 60/*TODO: timelimit from php.ini?*/))
      CSecuritySession::triggerFatalError('Unable to get session lock within 60 seconds.');// <===42

    $rs = CSecurityDB::Query("
      select SESSION_DATA
      from b_sec_session
      where SESSION_ID = '".$id."'
    ", "Module: security; Class: CSecuritySession; Function: read; File: ".__FILE__."; Line: ".__LINE__);
    $ar = CSecurityDB::Fetch($rs);
    if($ar)
    {
      $res = base64_decode($ar["SESSION_DATA"]);
      return $res;
    }

    return "";
  }

CSecurityDB::Lock

Код 
   function Lock($id, $timeout = 60)
   {
      static $lock_id = "";

      if($id === false)
      {
         if($lock_id)
            $rsLock = CSecurityDB::Query("DO RELEASE_LOCK('".$lock_id."')", "Module: security; Class: CSecurityDB; Function: Lock; File: ".__FILE__."; Line: ".__LINE__);
      }
      else
      {
         $rsLock = CSecurityDB::Query("SELECT GET_LOCK('".md5($id)."', ".intval($timeout).") as L", "Module: security; Class: CSecurityDB; Function: Lock; File: ".__FILE__."; Line: ".__LINE__);
         if($rsLock)
         {
            $arLock = CSecurityDB::Fetch($rsLock);
            if($arLock["L"]=="0")
               return false;
            else
               $lock_id = md5($id);
         }
      }
      return is_resource($rsLock);
   }
 

Пользователь 156811

Заглянувший

Сообщений: 6
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 05.02.2013

Добрый день! Столкнулся с аналогичной проблемой.

De

, удалось ли вам решить? Если да, то как?
 

Пользователь 223662

Заглянувший

Сообщений: 27
Баллов: 1
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 30.10.2013

 

Пользователь 223662

Заглянувший

Сообщений: 27
Баллов: 1
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 30.10.2013

Вернее да, но Сталинским методом. Просто снес битрикс на радость нервам и серверу.
 

Пользователь 33158

Заглянувший

Сообщений: 13
Авторитет:

0
Рейтинг пользователя:

0
Регистрация: 18.11.2008

А что представители Битрикс  молчат?
С 14 версией началась постоянная проблема:
«При выполнении скрипта возникла ошибка. Включить расширенный вывод ошибок можно в файле настроек .settings.php«
после какого-то кустарного скрипта который нужно было самому где-то найти и установить, появилась  эта проблема:
[ErrorException] E_USER_ERROR
Unable to get session lock within 60 seconds. (0)
/home/h/hitorg/public_html/bitrix/modules/security/classes/g­eneral/session.php:71
#0: trigger_error(string, integer)

…..
Что с проблемой то делать? некоторые стандартные  функции неработают!
Не редактируются компоненты, не могу изменить заказ клиента в админке…
 

Пользователь 234561

Заглянувший

Сообщений: 18
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 30.12.2013

#7

0

20.05.2014 15:44:54

Добрый день!
Кто то уже получил ответ по данной проблеме?

Код 
[ErrorException] E_USER_ERROR
Unable to get session lock within 60 seconds. (0)
/home/bitrix/www/bitrix/modules/security/classes/general/session.php:71
#0: trigger_error(string, integer)
   /home/bitrix/www/bitrix/modules/security/classes/general/session.php:71
#1: CSecuritySession::triggerFatalError(string)
   /home/bitrix/www/bitrix/modules/security/classes/general/session_db.php:42
#2: CSecuritySessionDB::read(string)
   
#3: session_start()
   /home/bitrix/www/bitrix/modules/main/include.php:298
#4: require_once(string)
   /home/bitrix/www/bitrix/modules/main/include/prolog_before.php:14
#5: require_once(string)
   /home/bitrix/www/bitrix/modules/main/include/prolog.php:11
#6: require_once(string)
   /home/bitrix/www/bitrix/header.php:1
#7: require(string)
   /home/bitrix/www/catalog/detail_section.php:2
#8: include_once(string)
   /home/bitrix/www/bitrix/modules/main/include/urlrewrite.php:152
#9: include_once(string)
   /home/bitrix/www/bitrix/urlrewrite.php:2
 

Пользователь 80243

Заглянувший

Сообщений: 14
Авторитет:

0
Рейтинг пользователя:

0
Регистрация: 05.01.2011

Выставите  max_execution_time = 60
 

Пользователь 80802

Заглянувший

Сообщений: 44
Баллов: 2
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 14.01.2011

#9

0

20.08.2014 00:59:47

Аналогичная проблема и так же при переносе.

Цитата
Горев Кирилл пишет:
Выставите max_execution_time = 60

Это как больной зуб лечить обезболивающим.

Ни кто не нашел больше решения?
 

Пользователь 105275

Заглянувший

Сообщений: 3
Авторитет:

0
Рейтинг пользователя:

0
Регистрация: 24.11.2011

#10

0

29.08.2014 15:11:15

Отключите хранение сессий в БД модуля безопасности.
 

Пользователь 57829

Гуру

Сообщений: 3754
Баллов: 320
Авторитет:

0
Рейтинг пользователя:

2
Регистрация: 17.02.2010

#11

0

29.08.2014 19:57:03

т.е. обратится в тп так никто и не удосужился?
 

Администратор

Сообщений: 10
Баллов: 3
Авторитет:

1
Рейтинг пользователя:

1
Регистрация: 08.05.2009

#12

0

06.10.2014 12:44:56

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

Пользователь 129527

Заглянувший

Сообщений: 11
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 21.05.2012

#13

0

18.12.2014 11:44:13

Цитата
Александр Корякин написал:
Эта ошибка говорит о том, что пользователь уже один раз обращался к сайту и запустил какой-то долгий процесс. При повторном обращении к сайту, когда выполняется еще первый запрос, выводится эта ошибка.
Необходимо определить, что именно делал пользователь, что при повторном обращении у него возникла эта проблема. Например, при переходе в список товаров этот список выводится больше минуты.

Пользователя зовут 1С и admin и это печаль :(
Процесс импорта и экспорта данных занимает в любом (моем) случае не менее 60 сек.
Будем игнорировать рекомендуемые настройки для безопасности — отключаем хранения сессий в БД.

Бизнес – это легко. А если случается так, что трудно, то это не означает, что невозможно.

 

Пользователь 303016

Заглянувший

Сообщений: 4
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 04.01.2015

#14

0

28.03.2015 00:32:23

Цитата
Павел Пешков написал:
отключаем хранения сессий в БД.

а как отключить, если в админку уже не войти?
 

Пользователь 303016

Заглянувший

Сообщений: 4
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 04.01.2015

#15

0

28.03.2015 08:09:16

 

Пользователь 129527

Заглянувший

Сообщений: 11
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 21.05.2012

#16

0

28.03.2015 15:00:01

Александр Егорин

, попробуй посмотреть в конфигурационных файлах системы dbconn.php или .settings.php
Если нет, тогда в БД нужно искать.

Бизнес – это легко. А если случается так, что трудно, то это не означает, что невозможно.

 

Пользователь 164017

Заглянувший

Сообщений: 2
Авторитет:

5
Рейтинг пользователя:

0
Регистрация: 25.04.2013

#17

0

20.06.2018 17:43:44

На дворе 2018 г., ошибка имеет место быть(((
 

Пользователь 302684

Постоянный посетитель

Сообщений: 94
Баллов: 11
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 25.12.2014

#18

0

26.06.2018 17:30:07

Аналогичная проблема на версии

18.0.1

при попытке открыть одновременно несколько страниц на которых впервые выполняется метод CFile::ResizeImageGet(), который соответственно вешает страницу, пока выполняется.

Если сообщение было для Вас полезным, лучшая благодарность это кнопка «Мне нравится» ;)

 

Пользователь 302684

Постоянный посетитель

Сообщений: 94
Баллов: 11
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 25.12.2014

#19

0

26.06.2018 17:32:45

Цитата
Александр Егорин написал:

Цитата
Павел Пешков  написал:
отключаем хранения сессий в БД.

а как отключить, если в админку уже не войти?

Вообще когда медленный запрос завершит свою работу, сайт должно отпустить. Или надо зайти с другого компа.

Если сообщение было для Вас полезным, лучшая благодарность это кнопка «Мне нравится» ;)

 

Пользователь 1388849

Заглянувший

Сообщений: 5
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 07.09.2017

#20

0

24.09.2020 10:27:02

Аналогичная ошибка, на тестовом сервере, где никто не особо не сидит :-
 

Пользователь 1388849

Заглянувший

Сообщений: 5
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 07.09.2017

#21

0

24.09.2020 12:40:56

Цитата
Андрей Дедов написал:
Аналогичная ошибка, на тестовом сервере, где никто не особо не сидит :-

Решили, ошибка была связана с отсутствием места на сервере БД.
 

Пользователь 13618

Эксперт

Сообщений: 1137
Баллов: 184
Авторитет:

10
Рейтинг пользователя:

0
Регистрация: 05.04.2011

Сертифицированный партнер

#22

0

08.05.2021 04:54:48

 

Пользователь 5557684

Заглянувший

Сообщений: 6
Авторитет:

0
Рейтинг пользователя:

0
Регистрация: 09.09.2021

#23

0

16.09.2021 12:25:44

Такая же ошибка сейчас и место на сервере есть? Кто решил?
 

Пользователь 8393

Заглянувший

Сообщений: 1
Авторитет:

1
Рейтинг пользователя:

0
Регистрация: 09.01.2007

#24

0

20.09.2021 17:34:31

Цитата
АЛЛА написал:
Такая же ошибка сейчас и место на сервере есть? Кто решил?

Проверьте размер таблицы b_user_session. Если её размер исчисляется гигабайтами, то попробуйте очистить её (все авторизованные пользователи разлогинятся).
Либо отключите хранение сессий в базе данных. Тут

https://dev.1c-bitrix.ru/user_help/settings/security/security_session.php

написано как.
 

Пользователь 2370559

Заглянувший

Сообщений: 6
Авторитет:

0
Рейтинг пользователя:

0
Регистрация: 08.08.2018

#25

0

23.01.2023 01:58:16

Ошибка ушла после того, как исправили настройки таймаутов MySQL.

Было так:  

PHP – 60 сек
Nginx – 300 сек
Mysql – 10 сек (connect_timeout) — это слишком мало.
Источник

Понравилась статья? Поделить с друзьями:
  • Error unable to locate the original valve api
  • Error unable to locate the configuration file hoi4
  • Error unable to load vpn connection editor
  • Error unable to load the nvidia drm kernel module
  • Error unclassifiable statement at 1 fortran