Bertrand LUPART

After a compilation, it ends up with a new file /sw/lib/pike/pike7.6/modules/Perl.so linked against

• /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
• /usr/lib/libSystem.B.dylib
• /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
• /System/Library/Perl/lib/5.8/libperl.dylib
• /usr/lib/libmx.A.dylib

features:
dynamic loading..... yes
threads............. yes (posix)
signal handler...... wait thread
cdebug.............. yes
rtldebug............ no
dmalloc............. no
mmx................. no (no mmx.h found)
byte code format.... ppc32
module reloc........ no
use machine code.... yes
int type............ long (4 bytes)
float type.......... double (8 bytes) (ieee big endian)
pointer size........ 4 bytes
svalue size......... 12 bytes (2+2+8)

Bz2................. yes (using libbz2)
DVB................. no (dependencies failed)
FFmpeg.............. yes (using libavcodec)
GLUT................ no (dependencies failed)
GTK................. yes
GTK.GlArea.......... no (dependencies failed)
GTK.GladeXML........ no (dependencies failed)
Gdbm................ yes
Gmp (bignums)....... yes (version 4.1.3, using libgmp)
Gnome............... no (dependencies failed)
Gz.................. yes (libz)
Image............... yes
Image.FreeType...... yes
Image.GIF........... yes
Image.JPEG.......... yes
Image.SVG........... yes
Image.TIFF.......... yes
Image.TTF........... yes
Image.XFace......... yes
Java................ yes (/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/../../JavaVM )
Kerberos............ yes
MIME................ yes
Math................ yes
Math.Transforms.FFT. yes
Mird................ no (libmird/mird.h not found)
Mysql............... yes (libmysqlclient)
Nettle.............. yes
Odbc................ yes
Oracle.............. no (dependencies failed)
PDF.PDFlib.......... yes
PDF.Panda........... no (dependencies failed)
Perl................ yes
Postgres............ yes
Regexp.PCRE......... yes (libpcre)
SDL................. yes
SDL_mixer........... no (dependencies failed)
Ssleay.............. no (use --with-ssleay to compile it)
sybase.............. no (dependencies failed)

See installation instructions: http://www.gotpike.org/PikeWiki/index.pike?page=Darwin+Fink

The fink info and patch files have been sent to the mailing list and should be available in the CVS soon.

What's new?

• compilation on i386 (thanx to http://helicopter.geek.nz/);
• testsuites are no more installed with the package;
• better SplitOff;
• added SVG, PostgreSQL and ffmpeg support;

I can provide binary packages for PowerPC. Please ask on the http://pike.ida.liu.se/forums/ using the [Fink] header. It should be possible to provide i386 packages too.

The summary can be viewed here: http://sourceforge.net/tracker/index.php?func=detail&aid=1358218&group_id=17203&atid=414256

Thanx to http://helicopter.geek.nz/, this package has been made usable on Intel Macs.

The nettle.info file has been posted to the mailing and will hopefully be in the CVS soon.

We use a bunch of custom 2nd level virtual hosting related modules as well as many custom RXML tags and containers to help our webmasters to builds websites and do complex applications, like online shops. And for the curious, we host some PHP apps too.

We noticed the performance of our webserver was decreasing for the last weeks. The sites were served more slowly and the load average of the Linux server went higher.

The 'ps' and 'top' command regularly showed the processus 'pike' on state 'D' (= uninterruptible sleep), which means we were waiting for some I/O.

We worked to find the bottleneck: all of our modules were audited and optimized, with little success: they should have been done the right way from the beginning :) We checked the Caudium configuration and some parts of the Caudium code, but nothing seemed to be wrong here either. Stracing Caudium didn't showed something usefull.

Then, we went down the filesystem. From what i could read on the net, ReiserFS could handle easily theses thousands of directories and files. So, nothing should be wrong here.

Thus, i was stuck in front of my top, showing pike regularly being in state 'D'. By decreasing the delay interval to 1 second (top -d1), i saw that when pike was in status 'D', a chmod process sometimes briefly showed up in the process list, on 'D' state itself.

After investigating, it appeared a shell script invoqued by the crontab was changing the permissions on some hundreds megabytes of data every minute on this server.

These data were never accessed by Caudium, it wasn't website data. But, they were on the same partition, and it was sufficient to dramatically slow down the webserver and some other services.

Since these data were constantly growing, 'chmod' took more and more time to complete, more and more slowing down other processes that accessed this filesystem.

The script being now fixed, my Caudium server happily serves its websites under a low load.

I did, because my busy Caudium box sometimes died with the following message: "Out of sockets (1024 active)".

I tried to increase the system limits before trying to reduce the number of used sockets in my own Caudium modules, but the operating system doc wasn't really clear. As a consequence, i wasn't sure i increased them well.

That's why it's know possible to know the current limits via the Caudium Configuration Interface (CIF), under Actions -> Status -> Limits Status.

The code is here: http://cvsweb.caudiumforge.net/cgi-bin/cvsweb.cgi/caudium/server/config_actions/limitsstatus.pike?cvsroot=caudium. It's totally backward-compatible with Caudium 1.4. My production servers are started with a custom start-caudium script which increases the limits at startup time and sports this CIF code.

Some options should be added in the CVS soon for being able to increase the limits at startup time.

Sometimes these modules couldn't write the data on their output file descriptor and hung. The fix was to have a callback for writing the data once the file descriptor can accept them. There's a new option ins the Caudium configuration interface which limit the real time the CGI module should wait for this callback. It's labelled "Limits: Timeout when network buffer is full".

Detailed fix for incomplete CGI pages: http://cvsweb.caudiumforge.net/cgi-bin/cvsweb.cgi/caudium/server/modules/scripting/cgi.pike.diff?r1=1.60;r2=1.56;cvsroot=caudium;f=h

The fix is available on CVS head for now, up from 1.60 and is totally compatible with Caudium 1.4. It should be backported soon and be available on forthcoming Caudium 1.4.8.

What can you see in your debug log now?

• CGI:Wrapper::done() Some data from the buffer hasn't been sent, yet

• CGI:Wrapper::destroy() killed while there was still data in the buffer

Check out http://caudium.net/server/docs/related/php4.rxml for more informations.

The problems i had in the first packages attempts seems related to building the documentation.

The pike7.6.info and pike7.6.patch files should be available in Pike 7.6 CVS soon.

http://pike.ida.liu.se/download/pub/pike/latest-stable/

The reason is that i'm facing a weird problem with nettle on this version which wasn't obvious to solve.

I was a bit busy with something else for now, but i expect finding the clue soon.