Таблица session грузит базу данных - страница 2 - Joomla 3.x: Общие вопросы

Ну а вобще это странно что за семь-восемь часов создается столько сессий что переполняется таблица .Что-то тут не чисто

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

Таблица продолжает рости. Не заметил, чтобы она чистилась.

А как получается так, что размер таблицы в МБ растет, а количество записей приблизительно держится? Под что уходит размер

надо смотреть содержимое поля data тогда, скорее всего оно разрастается, оно правда в json формате. Можете воспользоватся каким нибудь онлайн парсером http://json.parser.online.fr/

Может не таблица растет а логи?

Наткнулся еще на одно решение, только оно мне не очень по душе. Компонент Admin Tools Pro, у него есть функции - и оптимизации, и полной авто очистки таблицы session в заданный период.

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

на всякий случай вопрос, repair таблице sessions делался? может повреждена была?

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

проверил APC как session handler. действительно идут записи в таблицу sessions с data NULL. но после переключения обратно на handler database эти записи исчезли буквально сразу. хотя время сессии 15 мин. причем они не все одновременно исчезли, а по одной, относительно постепенно. я просто переключился обратно, т.к. в админку стало невозможно залогиниться. думаю стоит проанализировать сколько времени "висят" записи в sessions и посмотреть access log на предмет плохих ботов.

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

неплохая идея, возможно есть косяк с настройками MySQL.

XCache менее глючный, хотя я уже перешел на php 5.5 и Zend OPcache.
Ждем результата от топикстартера.
MySQL врятли тут виновен, скорее мемкеш(ед)...

http://joomlaforum.ru/index.php/topic,311917.msg1548695.html#msg1548695

157 сессий в интервале
GMT: Fri, 10 Apr 2015 13:35:25 GMT
GMT: Fri, 10 Apr 2015 13:40:20 GMT

как-то нездорово в любом случае.

157 за 5 мин? У вас там что, соц.сети? если счетчики (если они вообще имеются) не подтверждают это значение, то это однозначно воздействие извне csm, и не обязательно извне сервера. Меняйте хостера: либо он сам накручивает вам нагрузку, раскручивая вас на более дорогой тариф, либо у него с безопасностью никак. Либо вас ломают.

это я так оценил :-) по дампу таблицы sessions ТС от 10 апр. причем там time часто дублируется.

также в выборке ТС при session handler database - 3 записи и все на тему Yandex. YaBrowser-YandexMetrika-YandexBot. к чему бы это... Понятно, если так быстро YandexBot бы только ходил.

Вообщем включил я у себя memcache и действительно несмотря на это продолжаются вставки в таблицу.  В конце концов я докопался до истины. Все эти вставки происходят в методе checkSession() по адресу \libraries\cms\application\cms.php . Если в этом же файле в методе loadsession закоментить строки:

то лишнии строки в таблице создаватся не будут, сессия будет хранится в memcache и все вроде как работает. Как то кривоват механизм сессий на данный момент получается..

также в выборке ТС при session handler database - 3 записи и все на тему Yandex. YaBrowser-YandexMetrika-YandexBot. к чему бы это... Понятно, если так быстро YandexBot бы только ходил.

Это совпадение.

на всякий случай вопрос, repair таблице sessions делался? может повреждена была?

Делал! Не помогло

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

Проскакивала такая мысль, только это не просто. Что бы протестировать, нужна нагрузка. Это надо перенаправлять домен, а у меня еще поддомены с 10гиг файлами, которые надо перенести.

XCache менее глючный, хотя я уже перешел на php 5.5 и Zend OPcache.
Ждем результата от топикстартера.
MySQL врятли тут виновен, скорее мемкеш(ед)...

Кстати, пробовал XCache, результат тот же.

157 за 5 мин? У вас там что, соц.сети? если счетчики (если они вообще имеются) не подтверждают это значение, то это однозначно воздействие извне csm, и не обязательно извне сервера. Меняйте хостера: либо он сам накручивает вам нагрузку, раскручивая вас на более дорогой тариф, либо у него с безопасностью никак. Либо вас ломают.

Я не думаю, что хостер. Я и так не на дешевом тарифе, а нагрузка такая создается из-за session, что само железо не выдержит.

Возможно действительно влияние из вне. Проблема session у меня длится уже почти второй месяц и не было ни дня затишья. Через пару дней, после того как я создал эту тему, я писал, что таблица успокоилась (записи идут, но она не растет). Затишье длилось два дня, потом опять все вернулось. Это подталкивает на мысль, что это может быть влияние из вне...

Вообщем включил я у себя memcache и действительно несмотря на это продолжаются вставки в таблицу.  В конце концов я докопался до истины. Все эти вставки происходят в методе checkSession() по адресу \libraries\cms\application\cms.php . Если в этом же файле в методе loadsession закоментить строки...

Это действительно помогло! Закомментировал приведенные строки - в session ничего не прописывается (не растет) и нагрузку на базу не оказывает. Я уже начал довольствоваться "скрипт + cron". Спасибо большое zomby6888!

http://stackoverflow.com/questions/1260258/how-to-use-memcached-with-joomla

По поводу базы данных непонятно, там выше в методе стоит инетерсный коммент:

// TODO: At some point we need to get away from having session data always in the db.

Я на коммент тоже обратил внимание, потому и считаю данное поведение багом. zomby6888 предложил решение, считаю необходимым создать pull-request

Я на коммент тоже обратил внимание, потому и считаю данное поведение багом. zomby6888 предложил решение, считаю необходимым создать pull-request

Это не решение, если мы не знаем, почему оно работает. Ршение, это когда ты уверен в том, что делаешь и к чему это приведет.

Нет это не решение, конечно и для pull request оно не подойдет. Оно подойдет лишь как временное решение проблемы. Но внимание разработчиков на этот момент обратить желательно. Во первых этот метод checksession вызывается также в плагине авторизации. Я пробовал закоментить и там и после этого также все хорошо работает и записи в таблице не создаются(когда в качестве хранилища выбрана не БД). Тоесть там надо бы тоже сделать проверку на session_handler.

Во вторых сам метод и его название совершенно друг другу противоречат. Помимо проверки на наличие сессии там происходят еще и вставки в БД. Можно просто для каждого класса хранилища(наследуемого от JSessionStorage) добавить свой метод для проверки на наличие сессии(для JSessionStorageDatabase отдельный и отедельный для других типов хранилищ). Это позволит также избежать лишних запросов в БД для остальных типов хранилищ и увеличит производительность.

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

По поводу базы данных непонятно, там выше в методе стоит инетерсный коммент:

Под этим коментом я думаю там немного другое подразумевается. Кстатии на это я тоже хотел обратить внимание. Там идет проверка на наличие устаревших сессий в БД и их очистка в общем-то, которая запускается рандомно(может запустится, может нет в зависимости от $time % 2). Во первых в случае если хранилищем является memcaсhe то и чистить надо там, зачем опять же лишние запросы? Во вторых у JSessionStorageDatabase есть метод gc который вызывается во время сборки мусора. Почему не использовать его?

Без понятия. Сессии CMS для меня темный лес, никогда не лез с ними разбираться

В общем-то, zomby прав, считай - доказанный баг

Да я тоже особо не рабирался никогда, там не так просто вобщем-то разобратся. Но вот заинтересовался и как оказалось не все так гладко там

это уже есть в маркерах:
https://api.joomla.org/cms-3/markers.html#cms/application/cms.php

также см. это:
http://stackoverflow.com/questions/24217186/joomla-3-strange-session-storage-behaviour

Мне кажется, что не проблема в записях сессий в БД. Проблема в том, что у ТС они не удаляются. Я заметил, что при APC эти записи сессий в БД удаляются нормально. Таблица не растет. У кого есть memcache(d) проверьте то же самое.

это уже есть в маркерах:
https://api.joomla.org/cms-3/markers.html#cms/application/cms.php

также см. это:
http://stackoverflow.com/questions/24217186/joomla-3-strange-session-storage-behaviour

Мне кажется, что не проблема в записях сессий в БД. Проблема в том, что у ТС они не удаляются.

Сами записи удаляются. Но при этом сам размер таблицы в МБ растет.

Сами записи удаляются. Растет размер в МБ

итак, как я понимаю, мы пришли к проблеме с MySQL.

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

итак, как я понимаю, мы пришли к проблеме с MySQL.

Я изначально писал, что таблица растет именно в МБ, но при этом количество записей держится стабильно!

У кого есть memcache(d) проверьте то же самое

memcache можно настроить на локальном сервере.я на openserver настраивал для проверки. Сейчас уже нету времени этим заниматься

Я изначально писал, что таблица растет именно в МБ, но при этом количество записей держится стабильно!

ну тогда надо смотреть что в data, если сама таблица не повреждена. Может там массив сериализованный на 100500 записей.

Я изначально писал, что таблица растет именно в МБ, но при этом количество записей держится стабильно!

посмотрите на сервере не MySQL ли висит в тоp-e.

посмотрите на сервере не MySQL ли висит в тоp-e.

Не совсем понял вопрос!  тоp-e?