PHP sessions starting to fail

[jamie howard]

Hello there - we have a fairly busy server and we just started to have
problems with PHP sessions failing. We've never had this problem before and
to be honist, out server traffic is lower than it has been in prior months -
so I'm really not sure what could cause this.

Could anyone suggest some potentiol avenues to explore for reasons that
could cause PHP sessions to fail?

Thanks for any suggestions!

[Colin McKinnon]

jamie howard wrote:

Hello there - we have a fairly busy server and we just started to have
problems with PHP sessions failing. We've never had this problem before
and to be honist, out server traffic is lower than it has been in prior
months - so I'm really not sure what could cause this.

Could anyone suggest some potentiol avenues to explore for reasons that
could cause PHP sessions to fail?

Thanks for any suggestions!

erm, yes.

You could post to usenet saying what PHP version you're running. on what
platform, and what session handler you are using.

You might even say what you've checked already.

You could even explain what you mean by 'failing' does it fail to create a
session? does the session expire unexpectedly?

C.

[jamie howard]

Hi, sorry here is the additional information:
PHP version 4.3.3
Running on Linux Redhat 9
Running MySQL and PostGre and Apache1.3.22

OK, heres what happens on a typical failure:
Log in - no problem, browse site - fine for a few minutes, then,
sporadically I am redirected back to the login page for no apparent reason.

I am checking the session by isset($_SESSION['login'])

Cheers - Jamie

"Colin McKinnon" <co**************@andthis.mms3.com> wrote in message
news:d3*******************@news.demon.co.uk...

jamie howard wrote:

Hello there - we have a fairly busy server and we just started to have
problems with PHP sessions failing. We've never had this problem before
and to be honist, out server traffic is lower than it has been in prior
months - so I'm really not sure what could cause this.

Could anyone suggest some potentiol avenues to explore for reasons that
could cause PHP sessions to fail?

Thanks for any suggestions!

erm, yes.

You could post to usenet saying what PHP version you're running. on what
platform, and what session handler you are using.

You might even say what you've checked already.

You could even explain what you mean by 'failing' does it fail to create a
session? does the session expire unexpectedly?

C.

[jamie howard]

Also, I provide enclosed a dump from the shell comand "top"

Things we noted about it were:
1) Lots of mysql threads? not sure why - maybe we have a dodgy script?
2) Lots of httpd threads - is this normal
3) A few python threads - we don't know anything about python or why they
appear.
OK- heres the dump:

1:46pm up 5:50, 1 user, load average: 0.01, 0.00, 0.00
118 processes: 116 sleeping, 1 running, 1 zombie, 0 stopped
CPU states: 0.5% user, 0.7% system, 0.0% nice, 98.6% idle
Mem: 248620K av, 241784K used, 6836K free, 0K shrd, 16516K
buff
Swap: 787176K av, 5024K used, 782152K free 148944K
cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
872 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
874 mysql 10 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
875 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
876 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5230 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:02 mysqld
5261 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:01 mysqld
5448 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:01 mysqld
5449 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:01 mysqld
5466 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:02 mysqld
5468 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5472 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:03 mysqld
5474 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:01 mysqld
5488 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:03 mysqld
5492 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:01 mysqld
5664 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5665 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5712 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5734 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5742 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5762 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5841 mysql 14 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld
5907 mysql 15 10 7464 7464 2284 S N 0.0 3.0 0:00 mysqld

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
5234 apache 5 -10 10520 9.9M 7868 S < 0.0 4.0 0:06 httpd
5200 apache 5 -10 10268 9912 7796 S < 0.0 3.9 0:06 httpd
5454 apache 5 -10 10256 9900 7756 S < 0.0 3.9 0:02 httpd
5445 apache 5 -10 10176 9816 7676 S < 0.0 3.9 0:02 httpd
5473 apache 5 -10 10124 9764 7672 S < 0.0 3.9 0:02 httpd
5460 apache 6 -10 10076 9720 7716 S < 0.1 3.9 0:02 httpd
5461 apache 5 -10 9780 9420 7608 S < 0.0 3.7 0:02 httpd
5446 apache 5 -10 9212 8852 7724 S < 0.0 3.5 0:03 httpd
5469 apache 5 -10 9108 8748 7672 S < 0.0 3.5 0:02 httpd
5447 apache 5 -10 9056 8696 7668 S < 0.0 3.4 0:02 httpd
1099 root 5 -10 12128 11M 2296 S < 0.0 4.5 0:16 python2.1
1244 root 5 -10 12128 11M 2296 S < 0.0 4.5 0:00 python2.1
1245 root 5 -10 12128 11M 2296 S < 0.0 4.5 0:02 python2.1
1246 root 5 -10 12128 11M 2296 S < 0.0 4.5 0:00 python2.1
1247 root 5 -10 12128 11M 2296 S < 0.0 4.5 0:00 python2.1
1248 root 5 -10 12128 11M 2296 S < 0.0 4.5 0:00 python2.1
1249 root 5 -10 12128 11M 2296 S < 0.0 4.5 0:01 python2.1

"jamie howard" <jw*@web-engineer.co.uk> wrote in message
news:%x*******************@fe1.news.blueyonder.co. uk...

Hi, sorry here is the additional information:
PHP version 4.3.3
Running on Linux Redhat 9
Running MySQL and PostGre and Apache1.3.22

OK, heres what happens on a typical failure:
Log in - no problem, browse site - fine for a few minutes, then,
sporadically I am redirected back to the login page for no apparent
reason.

I am checking the session by isset($_SESSION['login'])

Cheers - Jamie

"Colin McKinnon" <co**************@andthis.mms3.com> wrote in message
news:d3*******************@news.demon.co.uk...

jamie howard wrote:

Hello there - we have a fairly busy server and we just started to have
problems with PHP sessions failing. We've never had this problem before
and to be honist, out server traffic is lower than it has been in prior
months - so I'm really not sure what could cause this.

Could anyone suggest some potentiol avenues to explore for reasons that
could cause PHP sessions to fail?

Thanks for any suggestions!

erm, yes.

You could post to usenet saying what PHP version you're running. on what
platform, and what session handler you are using.

You might even say what you've checked already.

You could even explain what you mean by 'failing' does it fail to create
a
session? does the session expire unexpectedly?

C.

[Colin McKinnon]

jamie howard wrote:

Log in - no problem, browse site - fine for a few minutes, then,
sporadically I am redirected back to the login page for no apparent
reason.
It's only the one server and there's no [transparent?] web proxy twixt you
and it?

Possible options:
- browser is forgetting whom you are
- server is deleting session prematurely
- scripts are changing new session

I'd suggest logging in, noting you session id (you only need the last, say 4
chars) playing around till it breaks then checking the session id.

Also find the dir where the sessions are stored, (if you've got a lot of
sessions you'll probably need more than 4 chars) and see if there is a file
name after your session id.
1) Lots of mysql threads? not sure why - maybe we have a dodgy script? (not threads - processes)
2) Lots of httpd threads - is this normal for a "fairly busy server" maybe. How many do you normally have?
3) A few python threads - we don't know anything about python or why they
appear.

Usually 'there's code running on my server and I don't know what it is nor
where it came from nor who is running it' is a bad sign. Try 'ps auxww |
grep python'

HTH

C.

[Daniel C. Bastos]

In article <%x*******************@fe1.news.blueyonder.co.uk >,
jamie howard wrote:

Hi, sorry here is the additional information:
PHP version 4.3.3
Running on Linux Redhat 9
Running MySQL and PostGre and Apache1.3.22

OK, heres what happens on a typical failure:
Log in - no problem, browse site - fine for a few minutes, then,
sporadically I am redirected back to the login page for no apparent reason.

I am checking the session by isset($_SESSION['login'])

Is your apache crashing? Check logs.

[JDS]

On Fri, 15 Apr 2005 12:35:07 +0000, jamie howard wrote:

Hi, sorry here is the additional information:
PHP version 4.3.3
Running on Linux Redhat 9
Running MySQL and PostGre and Apache1.3.22

OK, heres what happens on a typical failure:
Log in - no problem, browse site - fine for a few minutes, then,
sporadically I am redirected back to the login page for no apparent reason.

I am checking the session by isset($_SESSION['login'])

Cheers - Jamie

You said this thing used to work fine.

In my experience, when it comes to computers, the *last thing changed* is
the thing that is causing the problem. What is the last thing you did on
this system?

Now, I mean *anything*. Did you install a new disk? Did you install some
new software? Did you make any changes, however small, to the PHP
application?

No matter how seemingly unrelated the change is to the problem, computers
don't just spontaneously start doing goofy things (well, I guess they do
sometimes).

Just some debugging advice from a person who has been there before.

later...

--
JDS | je*****@go.away.com
| http://www.newtnotes.com
DJMBS | http://newtnotes.com/doctor-jeff-master-brainsurgeon/

[Chung Leong]

"jamie howard" <jw*@web-engineer.co.uk> wrote in message
news:%x*******************@fe1.news.blueyonder.co. uk...

Hi, sorry here is the additional information:
PHP version 4.3.3
Running on Linux Redhat 9
Running MySQL and PostGre and Apache1.3.22

OK, heres what happens on a typical failure:
Log in - no problem, browse site - fine for a few minutes, then,
sporadically I am redirected back to the login page for no apparent reason.
I am checking the session by isset($_SESSION['login'])

What is your session save path? It could be that some other process it
deleting your session files.

One problem I have run into in the past is storing objects in the session.
If you store an object in the session and another page, which doesn't have
the class definition, opens the session and modifies it, the object *might*
disppear.

[Craig Lawson]

Ok - i am posting more details on our problem....

The server is running the Ensim management software this is where the Python
threads were comming from.

Looking closer i have a hunch its mysql related, and/or a recent changed
script causing the problem.

Our mySql config is real simple however and there are no innodb tables in
any of the databases runinng on the server, so i dont think its innodb
related, however i am looking into removing innodb support support from my
mysql server if nothing turns up from the alalysis of all changed scripts.

It may simply be a performance issue as the server is now pushing upto 2000
sessions daily, and at times i have seen 500 sessions open in the /tmp
directory.

Any tips on how to tune LAMP server to maximise performance would be
apreaciated - or tips on where else we should be looking to cure this
problem.

Unfortunately we have no control on the hardware, which consists of 256mb of
ram, 40gb drive and 2ghz processor. Therefore performace optomisations need
to remain around the configuration of the services.

[R. Rajesh Jeba Anbiah]

Craig Lawson wrote:

Ok - i am posting more details on our problem....

The server is running the Ensim management software this is where the Python threads were comming from.

Looking closer i have a hunch its mysql related, and/or a recent changed script causing the problem.

Our mySql config is real simple however and there are no innodb tables in any of the databases runinng on the server, so i dont think its innodb related, however i am looking into removing innodb support support from my mysql server if nothing turns up from the alalysis of all changed scripts.
It may simply be a performance issue as the server is now pushing upto 2000 sessions daily, and at times i have seen 500 sessions open in the /tmp directory.
Probably that might be the reason for session to fail--as there may
not be any room for the session files to be created. The quick
workaround would be switching to DB based session handler--but that
will hit DB load.
Any tips on how to tune LAMP server to maximise performance would be
apreaciated - or tips on where else we should be looking to cure this problem.
If the problem is related to MySQL, you may try some caching
solutions
<http://groups.google.com/groups?selm=1111430495.275366.42540%40z14g2000cwz. googlegroups.com>

I would also recommend "High Performance MySQL" by Jeremy et al.
<http://www.oreilly.com/catalog/hpmysql/>
Unfortunately we have no control on the hardware, which consists of 256mb of ram, 40gb drive and 2ghz processor. Therefore performace optomisations need to remain around the configuration of the services.

To analyze the bottlenecks, you may need some good profilers like
APD <http://in2.php.net/apd> But, running profilers in a live site will
hit performance severely.

<rant>
FWIW, IMHO, though PHP is enterprise ready with lot of tools, PHP
programmers are far behind code optimization and etc unlike other
domain programmers.
</rant>

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Colin McKinnon]

R. Rajesh Jeba Anbiah wrote:

Craig Lawson wrote:

Ok - i am posting more details on our problem....

It may simply be a performance issue as the server is now pushing

upto 2000

sessions daily, and at times i have seen 500 sessions open in the

/tmp

directory.

Probably that might be the reason for session to fail--as there may
not be any room for the session files to be created. The quick
workaround would be switching to DB based session handler--but that
will hit DB load.

Putting the sessions into the DB will actually use up MORE space than files.
(although it should retain a 'high-water' mark) and more cpu.

Any tips on how to tune LAMP server to maximise performance would be
apreaciated - or tips on where else we should be looking to cure this

None to hand - how sure are you that there's a performance issue? It doesn't
sound like a lot of traffic. What you should be looking at is the load,
number of httpd processes and number of mysql processes.

There's a whole section in the mysql manual about tuning it. Turn on the
slow query logging.

Memory is likely to be tight on the spec cited.

HTH

C.

[Good Man]

"Craig Lawson" <cel[remove]@[remove]web-engineer.co.uk> wrote in
news:fj*******************@fe3.news.blueyonder.co. uk:

Unfortunately we have no control on the hardware, which consists of
256mb of ram, 40gb drive and 2ghz processor. Therefore performace
optomisations need to remain around the configuration of the services.

"Make my car go faster, but don't change anything about the engine."

[Micha³ Wo¼niak]

One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable Good Man's handwriting:

"Craig Lawson" <cel[remove]@[remove]web-engineer.co.uk> wrote in
news:fj*******************@fe3.news.blueyonder.co. uk:

Unfortunately we have no control on the hardware, which consists of
256mb of ram, 40gb drive and 2ghz processor. Therefore performace
optomisations need to remain around the configuration of the services.

"Make my car go faster, but don't change anything about the engine."

Yeah, remember you can do lots of things about the wheels, the fuel, and
so on. :)
Same thing's here - while there is no hw upgrade possible, I'm sure we
can think of a few sw optimizations, can't we?

Cheers
Mike

[Craig Lawson]

Thanks - looking into the MySQL config tonight.....

"Colin McKinnon" <co**************@andthis.mms3.com> wrote in message
news:d3*******************@news.demon.co.uk...

R. Rajesh Jeba Anbiah wrote:

Craig Lawson wrote:

Ok - i am posting more details on our problem....

It may simply be a performance issue as the server is now pushing

upto 2000

sessions daily, and at times i have seen 500 sessions open in the

/tmp

directory.

Probably that might be the reason for session to fail--as there may
not be any room for the session files to be created. The quick
workaround would be switching to DB based session handler--but that
will hit DB load.

Putting the sessions into the DB will actually use up MORE space than
files.
(although it should retain a 'high-water' mark) and more cpu.

Any tips on how to tune LAMP server to maximise performance would be
apreaciated - or tips on where else we should be looking to cure this

None to hand - how sure are you that there's a performance issue? It
doesn't
sound like a lot of traffic. What you should be looking at is the load,
number of httpd processes and number of mysql processes.

There's a whole section in the mysql manual about tuning it. Turn on the
slow query logging.

Memory is likely to be tight on the spec cited.

HTH

C.