By tomgf on

The software on my server

  • Drupal 5.1
  • PHP 5.0.4
  • MySQL 4.1.22
  • eAccelerator 0.9.5
  • Apache 2.0.40-21.21

The stats

These are the response values when calling <http://myserver.com/node/{nn}>:

without eAccelerator

  • Executed 103 queries in 433.66 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 1089.68 ms.
  • Memory used at devel_init(): 6.74 MB
  • Memory used at devel_shutdown(): 7.19 MB

with eAccelerator

  • Executed 103 queries in 77.8 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 197.16 ms.
  • Memory used at devel_init(): 0.09 MB
  • Memory used at devel_shutdown(): 0.44 MB

The performance boost is amazing.

The problem

As everybody noticed, there are some drawbacks with segmentation fault.

The extrange thing is that I start having segmentation fault errors but ONLY when calling /node/{nn} (and not when calling /node/{nn}/edit or any other admin page.

And on top of that the problem is not solved by restarting http.

The only solution I found consists of two steps:

  1. erase the cache
    rm -fR /tmp/eaccelerator/*
  2. restart the server
    /sbin/service httpd graceful

Any directions to find a more reliable solution to this problem?

⋅ Categories: Drupal 5.x

Comments

kbahey’s picture

kbahey commented

Different clients on different platform have experienced varying rates of seg faults with eAccelerator. Some get it every few hours, others get it every few days. Some never get it (but they are low volume).

The strange thing here is that it is consistent in one place.

I have not seen that in the past.

However, you are using PHP 5.0.x which was known for some issues. Can you upgrade to 5.1.x?

Also, there is a logwatcher script linked from the article you provided, but it will be of little use if no one can see /node/nnn.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

tomgf’s picture

tomgf commented

Thanks for your comment. Upgrading to 5.1.x is not a possibiltiy yet. Therefore, I am trying to trace this problem down and see if it can be solved without upgrading PHP.

It is very odd that the problem occurs just calling this particular URLs and not with any others. And it happens after a few page requests.

Still searching…

tomgf’s picture

tomgf commented

I have upgraded eAccelerator to the latest CVS (eAccelerator v0.9.6-svn302-dev) obtained here http://eaccelerator.net/wiki/Snapshots.

It's a tricky call and I sould be upgrading PHP instead, but this seems to solve the problem… (or at least to minimize it)

ksoonson’s picture

ksoonson commented

I posted similar issue at http://drupal.org/node/141612

Hope this problem can be resolved as soon as possible...

ksoonson’s picture

ksoonson commented

I posted some update at this node:

For me, the theme_links(); had problem so I modified this.

For more details, please see http://drupal.org/node/141612 and please modify your code as I did so that we can narrow down this issue. I am also testing the code so I am not sure whether this will fix this problem right now.

Thanks

chrisd’s picture

chrisd commented

Hi,

I provide binaries for eAccelerator on Windows. So I follow closely any issue with ea.

We've have had our first reports of a stable stack in a long time (1 year +): Windows + Apache 2.0.59 or 2.2.x + php 5.2.2 or 5.2.3 + ea 0.9.5.1. Following that report, I've been able to return my site sitebuddy.com to PHP as a module versus before running php with fastcgi recycled about every 15 minutes.

In other words try ea 0.9.5.1, if that does not solve your stability issues try upgrading to 5.2.2 or 5.2.3.

Both those php versions have been tested to work solid with ea 0.9.5.1 even with "high" traffic sites.

Here is the original report by a user of my site:
http://www.sitebuddy.com/PHP/Accelerators/eAccelerator_windows_binaries_...

Cheers,
Chris
Tech. articles with a WAMP+IIS+Drupal focus

kbahey’s picture

kbahey commented

One site has PHP 5.2.1 and eAccelerator 0.9.5.1 (Ubuntu Feisty), which is comparatively low traffic, but seg faults do happen occasionally.

The other is PHP 5.1.6 and eAccelerator 0.9.5 (Ubuntu Edgy), and has one or more per day. The site has very high traffic.

The reason of sticking with the above PHP versions is that they are the ones provided with their respective Ubuntu distro (Feisty and Edgy).
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba