Asked  7 Months ago    Answers:  5   Viewed   75 times

For some odd reason, just today our server decided to be very slow during the starting of sessions. For every session_start, the server either times out after 30 seconds, or it'll take about 20 seconds for it to start the session. This is very weird, seeing as it hasn't done this for a very long time (the last time our server did this was about 7 months ago). I've tried to change the session to run through a database instead, and that works fine, however, as our current website is built, it'd take days to go on every page and change the loading of sessions to include a new session handler. Therefore my question remains:

Why is it so slow, and why only sometimes?

We run on a dedicated hetzner server with 24GB's of ram, and a CPU fast enough to just run a simple webserver (a Xeon, I believe, but I'm not sure). We run debian on the server with an apache+fastcgi+php5 setup.

The server doesn't report much load, neither through server-status as well as the top command. Vnstat reports no problem whatsoever with our network link (again, that wouldn't result in a slow local session handling). IOtop reports no problem with processes taking over the entire harddrive. Writing to the tmp folder where the session files are located works fast if done through vim.

Again, to make this clear, my main concern here isn't whether or not we should switch to a DB or a memory-cached version of the sessions, it's simply to ask why this happens, because everything I take a look at seems to be working fine, except for the PHP itself.

EDIT: The maximum file in our PHP tmp directory is 2.9 MB, so nothing that should make an impact, I believe.

UPDATE: I did never figure out what was wrong and/or how to fix it, but the problem disappeared after we switched over to memcached/db sessions.



Have you tried session_write_close(); ? This will disable write-ability in session variables but you can still read data from them. And later when you need to write a session variable, reopen it.

I have also suffered from this problem but this thing worked like a charm. This is what i do:

session_start(); //starts the session
session_write_close();   // close write capability
echo $_SESSION['user']; // you can still access it
Wednesday, March 31, 2021
answered 7 Months ago

I solve this annoying problem by following instructions below:

  1. open /etc/php5/apache2/php.ini
  2. find ;session.save_path = "/tmp", this line may look also like this ;session.save_path = "/var/lib/php5"
  3. remove first semicolon from this line
  4. restart apache by executing sudo service apache2 restart

FYI: I work under Ubuntu 12.04 with apache2, php5, phpMyAdmin 4.0.5 so for different systems and servers file path may be a little different.

In case of any troubles check if directory from step 2. is writable for server.

Good luck.

Wednesday, March 31, 2021
answered 7 Months ago

Edit the file /usr/lib/php5/maxlifetime

The value should be in seconds. This file will actually also check your php.ini so I don't know why it wasn't working for you.

Thursday, July 29, 2021
answered 3 Months ago

Data dictionary or fixed object statistics might be old, try re-gathering them:

exec dbms_stats.gather_dictionary_stats;
exec dbms_stats.gather_fixed_objects_stats;
alter system flush shared_pool;

Even that does not necessarily gather statistics for all system objects. Some objects, like X$KFTBUE, must be gathered manually. Although that's a rare data dictionary problem that may not be relevant here.

If that doesn't work some next possible steps are looking at tools like SQL Tuning Advisor to create a profile, or using SQL Plan Management to force the optimizer to use a specific plan that has worked before. Tuning a data dictionary query can be very difficult since you don't have much control.

Thursday, September 23, 2021
Sergey Ryabov
answered 1 Month ago

what is the data type of .[Context] use the same datatype

right now you are using nvarchar(2) but that seems odd for something like 55, if you are not using the same data types you will get conversions which then cause scans

based on your updated question, it looks like it is varchar(255), then do this

WHERE this_.[Context] = @p0',N'@p0 varchar(255)',@p0='55'
Saturday, October 9, 2021
answered 2 Weeks ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :