I run apache in a chrooted environement already so this may not apply to everyone since I will not be discussing how to chroot apache, just php.
Install PHP5 as normal on you system and then carry out the following.
cp /usr/lib/apache/1.3/libphp5.so [chroot directory]/usr/lib/apache/1.3/libphp5.so
cp /usr/lib/libxml2.so.2 [chroot directory]/usr/lib/libxml2.so.2
Its as simple as that.
Postgresql compile on 2.8 2x2Mb intel
real 1m36.870s
user 2m43.138s
sys 0m10.617s
chrooting exim4
If you ever get this error while chrooting exim4 then make sure that you have copied over /etc/services into your chroot directory.
T=remote_smtp defer (-1): TCP port “smtp” is not defined for remote_smtp transport
http://www.conkers.net/
I spoke to conkers.net today about submitting my job site to be listed in as one of the jobsites where recruitment companies can submit jobs.
Everything was going swimmingly until they quoted me £250 for the priviledge. They have 564 sites listed which means they have made £141,000. This is before the actual agencies pay to use the service. I cannot afford to throw money at an unknown with no guarantee of getting any jobs added to my website.
I also had a look at gojobsite to see what they charge for advertising a job and it costs £200 for a one off advertisement for two weeks. Of course they have the user base but with some effort from recruiters I could probably do it for free if I could get the jobs added to uklug.
Installing bbBOARDv2
I have been looking for some decent bulleting board software recently and having been bitten by PhpBB severe lack of security and the fact that most PHP based BB bulleting boards ie vbulletin etc seem to have the same problem I started to look for alternatives. One alternative I found was bbBOARDv2 which uses Perl and is compatible with PostgreSQL which is a bonus in my book. I decided to try it and this was were the fun began.
For some reason it kept complaining that it was missing a curly bracket at the end of the script, this was odd because in a non mod_perl env it would work fine.
I added the curly brace and the script would now compile and it appeared to be working except that it wanted 2.2Gb of memory and spurted the following complaint.
Deep recursion on subroutine “Compress::Zlib::AUTOLOAD” at /usr/lib/perl5/Compress/Zl ib.pm line 87.
Woops! This is not so good. This would have killed my server if I had not caught it. I have now given up trying to install it because I don’t want it to bring down the server. I am awaiting some support which seems to be a long time arriving.
Chrooting Squid, Apache and Perl
Is fairly straight forward.
You will need to be able to use the following commands with some confidence
ldd
strace
rsync
cp
Tips. When copying files make sure your umask is set to 022 and alias cp as follows:
alias cp=”cp -p”
If you are copying over any perl XS files ie *.so files make sure you also use ldd on these. As an example the PostgreSQL drivers require:
ldd usr/lib/perl5/auto/DBD/Pg/Pg.so
libpq.so.3 => /usr/lib/libpq.so.3 (0xb7fbf000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7e89000)
libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0xb7e58000)
libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0xb7d59000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7cf1000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xb7cc4000)
libresolv.so.2 => /lib/tls/libresolv.so.2 (0xb7cb2000)
libnsl.so.1 => /lib/tls/libnsl.so.1 (0xb7c9d000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7c8e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7c8b000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7c68000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7c65000)
A quick way to find your shared object files is as follows.
find /chroot_directory_name/usr/ | grep perl | grep “.*\.so$”
You will already have copied most of the shared object files over while copying squid and apache but there are most likely a few extra ones you are going to need in particular if you are using the DBI.
storeDiskdInit: msgget: (28) No space left on device
2005/12/29 13:41:04| storeDiskdInit: msgget: (28) No space left on device
FATAL: msgget failed
Squid Cache (Version 2.5.STABLE9): Terminated abnormally.
CPU Usage: 0.018 seconds = 0.008 user + 0.010 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 0
This was remedied as follows:
echo 64 > /proc/sys/kernel/msgmni
echo 16384 > /proc/sys/kernel/msgmax
To make it permanent edit /etc/sysctl.conf and add:
kernel.msgmni = 64
kernel.msgmax = 16384
More details can be found here:
How do I configure message queues?
Installing PostgreSQL 8.1.1
]$ ./configure CFLAGS=’-O2′ –with-openssl –enable-thread-safety
]$ time make -j2
real 1m19.751s
user 2m4.832s
sys 0m11.613s
Tuning Postgres
The following is was what I noticed when comparing particular postgresql configuration parameters for an application I currently use.
This is for a particular select query which is heavily used. It is being run against a 3 column 10 million row table with a non unique index on one of the int4 columns. The query returns (123910 rows). All times are averages of several attempts at running the query and no other activity except that to run the OS was taking place at the time. Where the best and worst times differ by a noticeable amount I have added a second line to the row.
shared_buffers effective_cache
1024 200 Time: 843.300 ms
8192 200 Time: 793.345 ms
16384 200 Time: 813.399 ms
32768 200 Time: 360.111 ms Time: 401.952 ms
65536 200 Time: 379.023 ms Time: 439.706 ms
131072 200 Time: 387.866 ms Time: 404.930 ms
262144 200 Time: 362.229 ms Time: 384.344 ms
327680 200 Time: 359.975 ms Time: 383.517 ms
shared_buffers effective_cache
1024 1024 Time: 840.544 ms
1024 8192 Time: 837.187 ms
1024 16384 Time: 829.379 ms
1024 32768 Time: 826.749 ms
1024 65536 Time: 824.526 ms
1024 131072 Time: 808.480 ms
1024 262144 Time: 825.258 ms
1024 327680 Time: 817.206 ms
We can see here that the shared_buffers has the largest single affect on performance for this select statement. Would increaseing the effective cache setting while using the optimum shared bufffers chage anything?
shared_buffers effective_cache
32768 1024 Time: 361.477 ms Time: 364.341 ms
32768 8192 Time: 383.347 ms Time: 388.539 ms
32768 16384 Time: 422.892 ms Time: 425.068 ms
32768 32768 Time: 356.700 ms Time: 387.811 ms
32768 65536 Time: 360.410 ms Time: 406.472 ms
32768 131072 Time: 423.960 ms Time: 425.333 ms
32768 262144 Time: 386.507 ms Time: 392.272 ms
32768 327680 Time: 383.629 ms Time: 385.097 ms
It is quite plain from above that the most important parameter between shared_buffers and effective_cache for my select query is definitely shared_buffers.
Adding “order by column” and testing
sort_mem
1024 Time: 640.896 ms
8192 Time: 582.495 ms
16384 Time: 505.777 ms
32768 Time: 505.784 ms
We can see here that increasing the sort_mem has a good effect on performance.
Now adding a simple limit clause to the sorted results gives me another boost to the procedure.
limit
50000 Time: 391.164 ms
25000 Time: 350.564 ms
10000 Time: 325.975 ms
1000 Time: 311.234 ms
1 Time: 309.303 ms
We can see here that preparing the results has a large impact in performance. Something else that a lot of people miss is the order the columns are in, in the query used.
For instance asking for the colums in the order they are in in the table we get
Time: 360.379 ms
If we reverse the order of three columns we get.
Time: 405.506 ms
This is a big difference if the query is called a lot.
perl -d:DProf
I have been running a simple search engine tool on UKlug and I have noticed that things are getting a bit sluggish due to the amount of jobs in the database (300K+). Its not an astronomical amount but the method I am using is starting to strain against the hardware. I am going to rewrite it (article for another day) but for now is there anything I could do to speed things up?
When something just isn’t running as fast as expected then its time to break out the Perl profiler. The search engine has a mod_perl front end which is the first pain in the ass. I am fully conversant with the mod_perl performance tuning guide but trying to profile mod_perl is not as straight forward as the guide suggests.
Luckily I always use modules for the bulk of the work on any cgi scripts so I created a mock script to call out to the modules and then ran the profiler against this as a stand alone program.
]$ perl -d:DProf mock_script.pl
This confirmed my suspicion that the main problem was database access. There are a couple of Perl functions that could be faster but tuning these when the database is such a bottle neck would be an exercise in futility. I know I have tuned the database to a point where it is not going to get any faster so everything is pointing at either a faster machine or a rewrite.
It just so happens that I have a faster machine to hand so running the offending SQL with timings on I got the following times.
Slow machine:
Time: 3003.434 ms
Fast Machine:
Time: 1683.190 ms
This is a marked improvement over the slower machine but it still a hellish time to wait for some results that have yet to be displayed. So how can I reduce the time taken to retrieve the results? More to follow.