Guestbook broken?

hackerart · Post by **hackerart** » Tue Dec 26, 2006 7:31 pm

I have no idea, why my guestbook doesn't work anymore. hackerart.at/pages/guestbook.html opens a blank page and I have the same problem with a new blog of my daughter - http://dolphin-healing.uni.cc/ , where I removed the guestbook now, since it doesn't work. Since there are 2 blogs, I don't think, it is a special problem of my blog.

Maybe there is a relation to the updates I made. AFAIR it was something with "tag" I updated, as well es the Gallery2-plugin.

hackerart · Post by **hackerart** » Thu Dec 28, 2006 12:48 pm

I tried to open the guestbook a few minutes ago and got this message:

Fatal error: Maximum execution time of 30 seconds exceeded in /home/hacker/public_html/blog/plugins/serendipity_event_geotag/serendipity_event_geotag.php on line 255

Post by **garvinhicking** » Thu Dec 28, 2006 9:01 pm

Hi!

Did you modify the geotag plugin maybe? Some plugin is causing a timeout, as it seems?

HTH,
Garvin

hackerart · Post by **hackerart** » Thu Dec 28, 2006 9:54 pm

The plugin itself? No! But I configured the plugin of course. Unfortunately I do not remember which plugins I updated, one was the "Unified Sidebar Image Display" plugin and AFAIR one plugin is something with "tag". Maybe you know which plugins were modified in the last (2?) weeks.

Do I loose all the stored geotag-data, when I remove the plugin? If not, I will try to remove the geodata-plugin and have a look if the guestbook works again.

Post by **garvinhicking** » Thu Dec 28, 2006 9:58 pm

Hi!

You could temporarily disable the plugin if you use serendipity 1.1, by setting the plugin to "hidden/inactive".

However I believe the timeout is caused in another plugin...does the timeout also occur on admin pages, or only on your blogs frontend?

If it only occurs on your frontend, chances are that a Sidebar plugin is acting weird for you and taking up too much time.

Sadly PHP does not have an option to tell which PHP line/code/file is the cause of 29seconds operation; only the file where it hits the 30sec limit will be notified, but that might not be the culprit.

Maybe the only option is to create a duplicate test blog somewhere, import the SQL dump and then disable a plugin one after the other to see which one is causing the trouble?

HTH,
Garvin

hackerart · Post by **hackerart** » Thu Dec 28, 2006 10:17 pm

I use 1.0.4. Does it make sense to hide a sidbar-plugin?

Since it worked already I prefer to disable the 2 plugins I updated. Is there a log of the updates?

Post by **garvinhicking** » Thu Dec 28, 2006 10:21 pm

Hi!

Yes, hiding a sidebarplugin will also prevent its execution!

Update logs can be found in the CVS commit logs here:

http://php-blog.cvs.sourceforge.net/php ... l_plugins/

Browse to the directory of the plugin you want to inspect, then click on the main serendipity_(event|plugin)_blabla.php file and you will see the list of changes made to that file.

HTH,
Garvin

hackerart · Post by **hackerart** » Thu Dec 28, 2006 10:44 pm

Could it be, that the error occurs because my website is sometimes very slow? The hoster moved me to another server, which is a little bit faster now, but I am still not happy with it. At the moment there is an overload again. It didn't help to disable a few sidebar plugins. The Gallery-Plugin was not the problem. AFAIR the 2nd update was an event plugin. It looks like I have to forget the guestbook, since I don't want to deinstall all the events-plugins and it is not so easy for me to clone the blog for testing.

Code: Select all

 16:39:57  up 22 days,  5:16,  3 users,  load average: 11.29, 18.51, 11.91
141 processes: 136 sleeping, 1 running, 2 zombie, 2 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total   10.3%    0.0%   13.1%   0.0%     0.7%   70.4%    5.1%
           cpu00    9.3%    0.0%   12.9%   0.0%     0.5%   69.6%    7.3%
           cpu01   11.3%    0.0%   13.3%   0.0%     0.9%   71.2%    2.9%
Mem:  2057696k av, 1895984k used,  161712k free,       0k shrd,   37456k buff
                   1168132k actv,  577392k in_d,   26544k in_c
Swap: 2040244k av,  961252k used, 1078992k free                 1329588k cached

Post by **garvinhicking** » Thu Dec 28, 2006 11:01 pm

Hi!

Hm, I don't think the problem is related to the guestbook plugin. Your slowness of the website is the real clue.

A load of 11 is really bad. What is running on that server that is making it so slow?

You might need to cut down on event plugins to make s9y faster generally? Also upgrading to 1.1 will introduce some more memory and SQL performance imprvements.

Regards,
Garvin

hackerart · Post by **hackerart** » Thu Dec 28, 2006 11:24 pm

I agree with you Garvin, that a load of 11 is bad, but at the moment I am happy to have no loads of more than 30, sometimes 90. I have changed the hoster not so long ago and I don't want to change it again at the moment. It is a lot of work to setup everything.

It takes time, that they believe me, if I give them an advice, what to try. A few moments ago we found out, that they use 2 different version (5.5.6 and 6.2.5) of Imagemagick with a misconfigured path. AFAIR elder versions of IM can produce a lot of load and have a memory leak. Let's see if they upgrade IM.

I analyzed the system a little bit more and found out, it is pretty old, maybe this is a problem.

uname -r
2.4.21-47.0.1.ELsmp

Virtual Wire compatibility mode.
OEM ID: TYAN Product ID: S2881 APIC at: 0xFEE00000
Processor #0 Unknown CPU [15:5] APIC version 16
Processor #1 Unknown CPU [15:5] APIC version 16
I/O APIC #2 Version 17 at 0xFEC00000.
I/O APIC #3 Version 17 at 0xFEBFF000.
I/O APIC #4 Version 17 at 0xFEBFE000.
Processors: 2
xAPIC support is not present
Enabling APIC mode: Flat. Using 3 I/O APICs
Kernel command line: ro root=LABEL=/
Initializing CPU#0
Detected 1793.412 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 3578.26 BogoMIPS
Page-cache hash table entries: 524288 (order: 9, 2048 KB)
Page-pin hash table entries: 131072 (order: 7, 512 KB)
Dentry cache hash table entries: 262144 (order: 9, 2048 KB)
Inode cache hash table entries: 131072 (order: 8, 1024 KB)
Buffer cache hash table entries: 131072 (order: 7, 512 KB)
Memory: 2052964k/2097088k available (1671k kernel code, 39512k reserved, 1278k data, 228k init, 1179584k highmem)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)

Post by **garvinhicking** » Thu Dec 28, 2006 11:33 pm

Hi!

Are you running on a shared server, or a dedicated server? what other apps are running on the machine? Which PHP version, and are you using mod_php or CGI? Which apache version? Which database and version?

There are so many things, but a webserver IMHO should never run with a higher load than 6 or 7...

Everything above that means that disk I/O RAM is not sufficientl and that applications are not properly configured. It can easily produce a spiral of death (more childs = more memory, more CPU -> childs do not get finished -> more childs, more memory usage -> server will go down and not process any child tasks because there are too many)

Regards,
Garvin