Получить id сессии 1с
Обновлено: 07.07.2024
Методика выявления длительной транзакции, которая привела к значительному расходу tempdb
К таким транзакциям стоит относиться подозрительно и стараться их не допускать.
Проблемы, к которым могут приводить длительные транзакции, в первую очередь связаны с избыточным потреблением каких-либо ресурсов: избыточные блокировки, избыточное потребление tempdb при работе с MS SQL Server.
Информацию по типичным причинам избыточных блокировок вы сможете найти в статье "Типичные причины избыточных блокировок и методы оптимизации".
В этой методике будет рассмотрена ещё одно достаточно неприятное проявление - избыточное потребление места в tempdb при работе с MS SQL Server.
Методика выявления длительной транзакции, которая привела к значительному расходу tempdb
1 - Зафиксировать значительное потребление tempdb
В целом объем свободного места можно оценить даже простейшим запросом
Для оперативной реакции на рост объема tempdb можно использовать "Инциденты и генерацию оповещений в ЦКК".
2 - Найти номер транзакции в MS SQL Server Management Studio
На этом шаге мы понимаем, что сейчас происходит значительное потребление места в tempdb.Для всех систем, работающих с использованием Технологической Платформы 1С в режиме совместимости с версией 8.3. (и старше) эффективно будет выполнение запроса:
Первые две колонки - номер сессии с СУБД и длительность транзакции.
Если длительность транзакции значительная, то транзакция, скорее всего, та, которую мы искали.
На практике редко бывает (может быть, у вас было по-другому?), что одновременно будет выполняться множество именно длительных транзакций, относящихся к различным операциям.
В этом запросе вы не получите объем места, использованный транзакцией, но по длительности транзакции (косвенный признак) получается идентифицировать виновника в 99% случаев.
Запоминаем номер session_id
Если проблема совсем критичная, а пользователи не могут больше работать, то нужно будет на СУБД выполнить kill 123 , где 123 - номер session_idНо это на совсем крайний случай. В этом случае в технологическом журнале будет зафиксировано исключение и событие EXCP. Такая ситуация, например, выглядит так (пример искусственный, но всё же)
В этом примере можно увидеть искомую транзакцию
Есть более "полный" запрос, который также позволит получить нужный номер транзакции, особенно, если система работает в режиме совместимости с 8.2.
Однако, приведенный ниже запрос может выполняться несколько десятков секунд (будьте к этому готовы): DECLARE @curr_date as DATETIME
Если вы не стали рисковать и отменять транзакцию (вдруг выполняется очень важная операция?), расследуем дальше.
3 - Находим код, выполнение которого привело к длительному выполнению в транзакции
Открываем консоль администрирования кластера серверов.
Переходим на закладку сеансы.
Нас интересуют две колонки:
- Соединение с СУБД
Запоминаем номер сеанса.
Обратите внимание, что session_id = Соединение с СУБД.
Опять же, если будет очень плохо, можно завершить сеанс.
В технологическом журнале это будет выглядеть так:
Но удаление сеанса - на крайний случай.
4 - Выясняем, что делает этот сеанс
Открываем журнал регистрации, отбираем по номеру сеанса , смотрим, что сеанс делает.
Если не понятно, что делает сеанс (а он ещё работает) быстро настраиваем технологический журнал по этому сеансу
Копировать в буфер обменаЗдесь 321 - это номер сеанса.
В технологическом журнале нас интересуют в первую очередь стеки на встроенном языке.
5 - Воспроизводим и разбираем проблему
Необходимо повторять где-то на копии ровно эту операцию.
На копии нас интересует запрос и его план, при выполнении которого потребовался большой объем данных в СУБД.
Контекст сеанса 1С хранит в параметре ИмяПриложения соединениий с информационной базой, для того чтобы получить список сеансов текущей информационной базы можно воспользоваться фунцией ПолучитьСеансыИнформационнойБазы(), а номер текущего соединения - НомерСоединенияИнформационнойБазы().
Для простоты и удобства пример функции, которая получает контекст сеанса:
Вызвать функцию можно так:
Реализация, найденная в интернете и не решающая задачу:
Специальные предложения
Например для толстого клиента оно так и не ответит на вопрос - где же я нахожусь. На сервере толстого клиента, или на клиенте.
Но с оговорками да.. вполне себе вариант.
(3)Почему не скажет? Скажет. Проблема только с файловой базой и толстым клиентом. Но. в этом случае "Серверного контекста" НЕ СУЩЕСТВУЕТ - все вызовы идут только под контекстом "Толстого клиента" (под обычным или управляемым приложением), даже, если в указан переход в контекст сервера (например через общи модуль с вызовом сервера) - контекст останется "Толстый клиент". А зачем Вам иное - ведь - реально контекст именно и будет "Толстый клиент" - никакого серверного контекста ВООБЩЕ не будет - будет доступно всё то, что доступно толстому клиенту - т.е. ВСЁ! В отладчике контекст будет "Толстый клиент". Более того, в толстом клиенте игнорируется не только директива "Вызов сервера", но и директива "Сервер" - т.е. будут доступны и функции чисто серверных модулей - прямо с клиента. Так устроена платформа. Вот, для тонкого клиента в файловой базе - контексты уже будут разделены.
А для толстого клиента остаётся только проверить, что он толстый клиент и это файловая база. Это можно проверить ещё и так
Аналогично толстому клиенту, в файловой базе, ведёт себя и внешнее соединение (только вместо директивы "Клиент" отрабатывает директива "ВнешнееСоединение ", а директива "Сервер" по-прежнему отрабатывает, вернее игнорируется - серверный контекст полностью доступен в контексте внешнего соединения без "вызова сервера"). Разве что интерфейсные вызовы не доступны (доступно всё то, что доступно для внешнего соединения).
Или давая пользователям 1С такие же имена как в ОС.
Или прикручивая собственные костыли в 1С. Типа определять имя текущего пользователя в ОС, потом в 1С, и записывать все это дело в какой нибудь регистр сведений.
Нормальных средств для файловой базы в терминале нет
Все базы файловые.
Есть несколько вариантов того, как работают пользователи -
1 Пользователи под уникальными именами заходят в терминальной сессии(UserTS) и работают под одним пользователем(User1С) в одной базе в 1С
2 Пользователи под уникальными именами заходят в терминальной сессии и открывают каждый свою уникальную базу в 1С.
Проблема 1
Как при варианте 1 узнать какой UserTS сидит в известной базе как User1С. Т.к. User1С у все одинаковый получается что в базе сидят 10 например пользователей User с уникальными ID.
Проблема 2
Как при варианте 2 узнать какой UserTS сидит в какой базе 1С.
Хотел сразу тебе это посоветовать, но не думал что тебе это НАСТОЛЬКО необходимо.
Есть путь попроще, с доработкой 1С, как я писал выше - с определением пользователей и записью куда нить в 1С. Потом используя внешнее соединение собирать данные о пользователях со всех баз. Хотя, кому как проще.
В твоем варианте с хендлами не нужно вносить изменения в 1С, т.е. не будет зависимости от конфигурации - универсальная консоль получится. Кстати, если напишешь - поделишься? Время от времени тоже есть необходимость определять кто завис в базе.
Думаю сделаю без проблем.
Вот возник технический вопрос.
Я правильно понимаю:
При открытии Базы, данные пользователя базы(если был выбран) + имя ПК + дата и т.д. записываются в таблицу в базу данных. В системе данные нигде не фигурируют?
Я узнал как найти имя пользователя 1С, который вошел в конкретную базу. Опять-же уже имея путь к базе и имя пользователя системы.
Осталось лишь реализовать программно, и будет мега тулза для терминального сервера.
Собственно вот:
Я решил пока не заморачиваться с процессами, сделал все проще - Мы знаем имя пользователя из пути к профилю,мы знаем о открытии базы по .lсk.
Минусы:
- Открытые базы завершенные "резетом" и не открытые снова считаются как открытые, т.к. файл .lсk остается.
- Если пользователя переименовали, а профиль остался старый - будет неверное имя пользователя
- Если 1 пользователь зашел под разными именами в 1 базу, будет показано последнее имя под которым он заходил
- не стал заморачиваться сохранением конфигов.
- не стал автоматом настраивать пути
Прикреплённый файл 1___user_finder_RAD_2010.rar (362,01 Кбайт, скачиваний: 221)
Всем хорошего дня. Перед вами первая статья из серии PHP для начинающих разработчиков. Это будет необычная серия статей, тут не будет echo "Hello World" , тут будет hardcore из жизни PHP программистов с небольшой примесью «домашней работы» для закрепления материала.
Изначально подразумевали, что по этому протоколу будет только HTML передаваться, отсель и название, а сейчас чего только не отправляют и =^.^= и（•_ㅅ_•）
А вот пример ответа:
- При авторизации пользователя, сервер генерирует и запоминает уникальный ключ — идентификатор сессии, и сообщает его браузеру
- Браузер сохраняет этот ключ, и при каждом последующем запросе, его отправляет
Т.е. если украсть cookie из вашего браузера, то можно будет зайти на вашу страничку в facebook от вашего имени? Не пугайтесь, так сделать нельзя, по крайней мере с facebook, и дальше я вам покажу один из возможных способов защиты от данного вида атаки на ваших пользователей.
Давайте теперь посмотрим как изменятся наши запрос-ответ, будь там авторизация:
Метод у нас изменился на POST, и в теле запроса у нас передаются логин и пароль. Если использовать метод GET, то строка запроса будет содержать логин и пароль, что не очень правильно с идеологической точки зрения, и имеет ряд побочных явлений в виде логирования (например, в том же access.log ) и кеширования паролей в открытом виде.
Ответ сервер будет содержать заголовок Set-Cookie: KEY=VerySecretUniqueKey , что заставит браузер сохранить эти данные в файлы cookie, и при следующем обращении к серверу — они будут отправлены и опознаны сервером:
PHP и сессия
Я надеюсь, у вас уже установлен PHP на компьютере, т.к. дальше я буду приводить примеры, и их надо будет запускать
Вот вам статейка на тему PHP is meant to die, или вот она же на русском языке, но лучше отложите её в закладки «на потом».
Перво-наперво необходимо «стартовать» сессию — для этого воспользуемся функцией session_start(), создайте файл session.start.php со следующим содержимым:
Запустите встроенный в PHP web-server в папке с вашим скриптом:
Там будет много чего, интересует нас только вот эта строчка в ответе сервера (почистите куки, если нет такой строчки, и обновите страницу):
Увидев сие, браузер сохранит у себя куку с именем `PHPSESSID`:
PHPSESSID — имя сессии по умолчанию, регулируется из конфига php.ini директивой session.name, при необходимости имя можно изменить в самом конфигурационном файле или с помощью функции session_name()
И теперь — обновляем страничку, и видим, что браузер отправляет эту куку на сервер, можете попробовать пару раз обновить страницу, результат будет идентичным:
Итого, что мы имеем — теория совпала с практикой, и это просто отлично.
Следующий шаг — сохраним в сессию произвольное значение, для этого в PHP используется супер-глобальная переменная $_SESSION , сохранять будем текущее время — для этого вызовем функцию date():
Обновляем страничку и видим время сервера, обновляем ещё раз — и время обновилось. Давайте теперь сделаем так, чтобы установленное время не изменялось при каждом обновлении страницы:
Обновляем — время не меняется, то что нужно. Но при этом мы помним, PHP умирает, значит данную сессию он где-то хранит, и мы найдём это место…
Всё тайное становится явным
По умолчанию, PHP хранит сессию в файлах — за это отвечает директива session.save_handler, путь по которому сохраняются файлы ищите в директиве session.save_path, либо воспользуйтесь функцией session_save_path() для получения необходимого пути.
В вашей конфигурации путь к файлам может быть не указан, тогда файлы сессии будут хранится во временных файлах вашей системы — вызовите функцию sys_get_temp_dir() и узнайте где это потаённое место.
Так, идём по данному пути и находим ваш файл сессии (у меня это файл sess_dap83arr6r3b56e0q7t5i0qf91 ), откроем его в текстовом редакторе:
Как видим — вот оно наше время, вот в каком хитром формате хранится наша сессия, но мы можем внести правки, поменять время, или можем просто вписать любую строку, почему бы и нет:
Для преобразования этой строки в массив нужно воспользоваться функцией session_decode(), для обратного преобразования — session_encode() — это зовется сериализацией, вот только в PHP для сессий — она своя — особенная, хотя можно использовать и стандартную PHP сериализацию — пропишите в конфигурационной директиве session.serialize_handler значение php_serialize и будет вам счастье, и $_SESSION можно будет использовать без ограничений — в качестве индекса теперь вы сможете использовать цифры и специальные символы | и ! в имени (за все 10+ лет работы, ни разу не надо было :)
Напишите свою функцию, аналогичную по функционалу session_decode() , вот вам тестовый набор данных для сессии (для решения знаний регулярных выражений не требуется), текст для преобразования возьмите из файла вашей текущей сессии:
Так, что мы ещё не пробовали? Правильно — украсть «печеньки», давайте запустим другой браузер и добавим в него теже самые cookie. Я вам для этого простенький javascript написал, скопируйте его в консоль браузера и запустите, только не забудьте идентификатор сессии поменять на свой:
Вот теперь у вас оба браузера смотрят на одну и туже сессию. Я выше упоминал, что расскажу о способах защиты, рассмотрим самый простой способ — привяжем сессию к браузеру, точнее к тому, как браузер представляется серверу — будем запоминать User-Agent и проверять его каждый раз:
По шагам
А теперь поясню по шагам алгоритм, как работает сессия в PHP, на примере следующего кода (настройки по умолчанию):
- после вызова session_start() PHP ищет в cookie идентификатор сессии по имени прописанном в session.name — это PHPSESSID
- если нет идентификатора — то он создаётся (см. session_id()), и создаёт пустой файл сессии по пути session.save_path с именем sess_ , в ответ сервера будет добавлены заголовки, для установки cookie =
- если идентификатор присутствует, то ищем файл сессии в папке session.save_path :
- не находим — создаём пустой файл с именем sess_ (идентификатор может содержать лишь символы из диапазонов a-z , A-Z , 0-9 , запятую и знак минус)
- находим, читаем файл и распаковываем данные (см. session_decode()) в супер-глобальную переменную $_SESSION (файл блокируется для чтения/записи)
- когда скрипт закончил свою работу, то все данные из $_SESSION запаковывают с использованием session_encode() в файл по пути session.save_path с именем sess_ (блокировка снимается)
А есть ли жизнь без «печенек»?
PHP может работать с сессией даже если cookie в браузере отключены, но тогда все URL на сайте будут содержать параметр с идентификатором вашей сессии, и да — это ещё настроить надо, но оно вам надо? Мне не приходилось это использовать, но если очень хочется — я просто скажу где копать:
А если надо сессию в базе данных хранить?
Для хранения сессии в БД потребуется изменить хранилище сессии и указать PHP как им пользоваться, для этой цели создан интерфейс SessionHandlerInterface и функция session_set_save_handler.
Отдельно замечу, что не надо писать собственные обработчики сессий для redis и memcache — когда вы устанавливаете данные расширения, то вместе с ними идут и соответствующие обработчики, так что RTFM наше всё. Ну и да, обработчик нужно указывать до вызова session_start() ;)Реализуйте SessionHandlerInterface для хранения сессии в MySQL, проверьте, работает ли он.
Это задание со звёздочкой, для тех кто уже познакомился с базами данных.
Когда умирает сессия?
За время жизни сессии отвечает директива session.gc_maxlifetime. По умолчанию, данная директива равна 1440 секундам (24 минуты), понимать её следует так, что если к сессии не было обращении в течении заданного времени, то сессия будет считаться «протухшей» и будет ждать своей очереди на удаление.
Интересен другой вопрос, можете задать его матёрым разработчикам — когда PHP удаляет файлы просроченных сессий? Ответ есть в официальном руководстве, но не в явном виде — так что запоминайте:
Сборщик мусора (garbage collection) может запускаться при вызове функции session_start() , вероятность запуска зависит от двух директив session.gc_probability и session.gc_divisor, первая выступает в качестве делимого, вторая — делителя, и по умолчанию эти значения 1 и 100, т.е. вероятность того, что сборщик будет запущен и файлы сессий будут удалены — примерно 1%.
Измените значение директивы session.gc_divisor так, чтобы сборщик мусора запускался каждый раз, проверьте что это так и происходит.Самая тривиальная ошибка
Ошибка у которой более полумиллиона результатов в выдаче Google:
Cannot send session cookie — headers already sent by
Cannot send session cache limiter — headers already sent
Для получения таковой, создайте файл session.error.php со следующим содержимым:
Во второй строке странная «магия» — это фокус с буфером вывода, я ещё расскажу о нём в одной из следующих статей, пока считайте это лишь строкой длинной в 4096 символов, в данном случае — это всё пробелы
Запустите, предварительно удалив cookie, и получите приведенные ошибки, хоть текст ошибок и разный, но суть одна — поезд ушёл — сервер уже отправил браузеру содержимое страницы, и отправлять заголовки уже поздно, это не сработает, и в куках не появилось заветного идентификатора сессии. Если вы стокнулись с данной ошибкой — ищите место, где выводится текст раньше времени, это может быть пробел до символов <?php , или после ?> в одном из подключаемых файлов, и ладно если это пробел, может быть и какой-нить непечатный символ вроде BOM, так что будьте внимательны, и вас сия зараза не коснется (как-же,… гомерический смех).
Для проверки полученных знаний, я хочу, чтобы вы реализовали свой собственный механизм сессий и заставили приведенный код работать:
Для осуществления задуманного вам потребуется функция register_shutdown_function()
Блокировка
Ещё одна распространённая ошибка у новичков — это попытка прочитать файл сессии пока он заблокирован другим скриптом. Собственно, это не совсем ошибка, это недопонимание принципа блокировки :)
Но давайте ещё раз по шагам:
- session_start() не только создаёт/читает файл, но и блокирует его, чтобы никто не мог внести правки в момент выполнения скрипта, или прочитать не консистентные данные из файла сессии
- блокировка снимается по окончанию выполнения скрипта
«Воткнутся» в данную ошибку очень легко, создайте два файла:
Теперь, если вы откроете в браузере страничку lock.php , а затем в новой вкладке откроете start.php то увидите, что вторая страничка откроется только после того, как отработает первый скрипт, который блокирует файл сессии на 10 секунд.
Есть пару вариантов, как избежать подобного явления — «топорный» и «продуманный».
«Топорный»
Использовать самописный обработчик сессий, в котором «забыть» реализовать блокировку :)
Чуть лучше вариант, это взять готовый и отключить блокировку (например у memcached есть такая опция — memcached.sess_locking) O_o
Потратить часы на дебаг кода в поисках редко всплывающей ошибки…
«Продуманный»
Куда как лучше — самому следить за блокировкой сессии, и снимать её, когда она не требуется:
— Если вы уверенны, что вам не потребуется вносить изменения в сессионные данные используйте опцию read_and_close при старте сессии:
Таким образом, блокировка будет снята сразу по прочтению данных сессии.
— Если вам таки нужно вносить изменения в сессию, то после внесения оных закрывайте сессию от записи:
Чуть выше был приведён листинг двух файлов start.php и lock.php , создайте ещё файлы read-close.php и write-close.php , в которых вы будете контролировать блокировку перечисленными способами. Проверьте как работает (или не работает) блокировка.В заключение
В этой статье вам дано семь заданий, при этом они касаются не только работы с сессиями, но так же познакомят вас с MySQL и с функциями работы со строками. Для усвоения этого материала — отдельной статьи не нужно, хватит и мануала по приведенным ссылкам — никто за вас его читать не будет. Дерзайте!
Читайте также: