Sudden and massive increase of the database, session table

Omeka S
1

Hi,

On a Omeka S installation (4.0.1), I noticed a sudden and massive increase of the mysql database. The database was ~150M and in one day jumps to 3.2G with no activities in the admin side.

The tables ‘session’ and ‘log’ are concerned.

image
image1407×135 51.4 KB

image
image1461×157 60.5 KB

I understand the log “table” which contains errors I can fix.

I am more confused about the “session” table. It contains 1948708 lines of this kind.

image
image981×585 159 KB

And the ‘BLOB’ data is always a session-data.bin file with information such as.

__Laminas|a:2:{s:20:"_REQUEST_ACCESS_TIME";d:1691479286.297107;s:6:"_VALID";a:1:{s:28:"Laminas\Session\Validator\Id";s:40:"sib5mt6q6i58cq07c7evvp6aijlh07lg70vjfj5p";}}

or

__Laminas|a:2:{s:20:"_REQUEST_ACCESS_TIME";d:1701257204.72632;s:6:"_VALID";a:1:{s:28:"Laminas\Session\Validator\Id";s:26:"5c28sgjih6jacrnd8lu7c4glfr";}}EasyAdmin|O:26:"Laminas\Stdlib\ArrayObject":4:{s:7:"storage";a:2:{s:14:"lastBrowsePage";a:1:{s:5:"admin";a:1:{s:5:"items";s:342:"/s/correspondance/rech_correspondance?q=&facet%5Bahpo:sentBy%5D%5B0%5D=Bertrand,%20Marcel&facet%5Bahpo:sentBy%5D%5B1%5D=Mittag-Leffler,%20G%C3%B6sta%20(1846-1927)&facet%5Bahpo:sentTo%5D%5B0%5D=Faidherbe,%20Louis&facet%5Bahpo:sentTo%5D%5B1%5D=Hertz,%20Heinrich%20Rudolph%20(1857-1894)&facet%5Bahpo:sentTo%5D%5B2%5D=Comon,%20Louis%20(1854-1918)";}}s:9:"lastQuery";a:1:{s:5:"admin";a:1:{s:5:"items";a:2:{s:1:"q";s:0:"";s:5:"facet";a:2:{s:11:"ahpo:sentBy";a:2:{i:0;s:16:"Bertrand, Marcel";i:1;s:34:"Mittag-Leffler, Gösta (1846-1927)";}s:11:"ahpo:sentTo";a:3:{i:0;s:16:"Faidherbe, Louis";i:1;s:35:"Hertz, Heinrich Rudolph (1857-1894)";i:2;s:24:"Comon, Louis (1854-1918)";}}}}}}s:4:"flag";i:2;s:13:"iteratorClass";s:13:"ArrayIterator";s:19:"protectedProperties";a:4:{i:0;s:7:"storage";i:1;s:4:"flag";i:2;s:13:"iteratorClass";i:3;s:19:"protectedProperties";}}

I wonder what is exactly this table and how can it could grow to almost 2G?

image
image1420×765 44.1 KB

2

It is probably a robot that access your site?

By the way, this is a common issue and you can truncate the table without issue (except log out users).

I see you use the module Easy Admin, so you can remove these logs and sessions in the matching tasks in the section “database”.

3

Thanks Daniel.

I purged the session and log tables.

The “session” one is still filling. I guess probably a bot scraping the website (is it possible that it is someone using Osii module from another Omeka S?).

If it is a good idea (?), is there a way to disable/prevent the logging of the session table to avoid any saturation?

4

The session table is needed for any user sessions; it’s what underlies logins, etc.

When it grows very very large as you’re seeing, that’s often a sign that the server has session garbage collection disabled (i.e., the php.ini setting session.gc_probability set to 0). Some servers or distributions do this with the intention of cleaning out sessions using a cron job instead, but those cron jobs only work against PHP’s default file-based sessions.

5

Thanks John. Good to know!

I had indeed this option set to 0 on my server (running debian). I changed it.

6

Sorry to reopen this issue.

I have still this problem from time to time. When a bot scrapes this Omeka S installation, the session table grows very fast until there is no space left. We have several Omeka S on the same infrastructure and only this website is affected (I do not know if it because this one is more popular with bots or for some other reason).

I can manually purge the session table but it is not a automatic solution.

This Omeka S installation is on two different virtual machines (both debian). Omeka S files are in the VM1 and the mysql database is in VM2. Both VM have the setting session.gc_probability set to 1 in the /etc/php/8.2/apache2/php.ini

What can I do?