Month: May 2008

Performance statistics
The OpenVMS bootcamp must have caused quite some load on Diana – MySQL crashed almost every two days with the known error: “not enough core”. Internet access was very, very slow at times but the hotel network was probably heavily loaded as well.
The web server usage statistics shows some increase, but due to the scaling of both output and number of accesses, it’s not that clear:

Regardless the exact cause – that needs to be determined using the T4 output of these days – it is more visible in the HyperSpy output:

Note the increment in CPU load from May 14th, and, foremost, May 18th, when the bootcamp really started.

memory load seems pretty much the same, but in detail, it’sfar more peaking then before – and page file usage – the spiky line below – almost doubled.

It looks rather flat – but that is caused by the spike on the left: a problem that at ties occurs with my Windows-based FTP client. With more detail, it’s notable that the number of processes is far more flat since May 18th.

As noted with the pagefile usage, the pagefault rate has gone up during the bootcamp – to be expected with an increasing number of processes and heavy database load.

By far most dramatic: Buffered IO. The only explanation I can give is the amount of data written to SYS$OUTPUT by the PHP engine that drives the blogs.

Because data comes off the disk, it’s obvious that the direct IO rate increased as well – tripled – during the bootcamp. (The high spikes mark the end-of-week processing on Monday, the low ones the end-of-day processing)

I expect that the load will drift to normal proportins in the week after the bootcamp. At that time I will be able to correlate all aspects of the system using T4 output.

(well, 17-May-2008 at almost 19:00, local time in the US)
PHP
Running the new PHP engine now for well over a week, and no HPARITHM errors so far, nor the weird DEBUG messages. But in accessing MySQL there are these messages in the admin panel:

WordPress database error: [Unknown MySQL error]
SELECT option_value FROM sm_options WHERE option_name = 'rss_0ff4b43bd116a9d8720d689c80e7dfd4' LIMIT 1
just before the WordPress Development Blog chapter, and these:

WordPress database error: [Unknown MySQL error]
SELECT option_value FROM sm_options WHERE option_name = 'rss_867bd5c64f85878d03a060509cd2f92c' LIMIT 1

WordPress database error: [Lost connection to MySQL server during query]
SELECT option_name FROM sm_options WHERE option_name = 'rss_867bd5c64f85878d03a060509cd2f92c'

occur just before the WordPress news header.

I tried to check this with phpMyAdmin, and found there that the current agent is, again, MySQL 3:

MySQL client version: 3.23.49

So I do have to rebuild the MySQL engine again.
But since the blogs have no problem with this, I leave it for now.

XP SP3
A requirement for the OpenVMS bootcamp is to have your system (that connects to the bootcamp LAN) to be up-to-date, and therefore Demeter, the company laptop, has been upgraded: ServicePack 3 has been installed. It takes quite a lot of time to download, verify (especially that part!) and install the package. For safety, a backup has been made of the Windows directory, so reversing should not be a problem.
After installation and reboot, it seems all is well. Auto-update has been left switched off – I like to keep things in my own hand :). Just wait a while, but when all is really well, the backup can be removed – it takes over 1 Gb on a not-to-big disk,

Remote management
Although I’m not at my normal location – way from that – I’ll be able to keep an eye on the systems, the only thing I won’t be able to do is a manual start the system. When needed, there are other ways to get that done.
But scanning log files and do some activity that does not require a reboot (something to be avoided anyway, and never an issue on Diana :)) can be done over the Internet.
Some weird messages were returned on the Admin pages: Unknown MySQL errors accessing the blog database, on one of the rss feeds. Something to look into, but for the rest it all works.

PHP ECO2 problem solved
One of the suggestions on the ITRC was to use the undocumented SET WATCH FILE facility to find out what exactly was loaded. As it turned out, there was definitively something wrong in loading the PHP extensions. Whatever I tried, it always stopped at some point – after loading the first or second. It didn’t matter what I left in, or out, I always got the ACCVIO error.
This is the log I kept of these tests.

To keep all information into one file, I created a small test procedure to be run in batch, producing lots of output but having all data at hand in one logfile. One action taken was examining the link date of every executable:

$loop1:
$ f = f$search("PHP_ROOT:[extensions]*.EXE;1")
$ if f .eqs. "" then goto loop1end
$ write sys$output 'f'PHP_ROOT:[extensions]*.EXE;1
$ pipe analyze/image 'file' | search sys$pipe link
$ goto loop1
$loop1end:


PHP_ROOT:[extensions]*.EXE;1 would be the old PHP version, and PHP_ROOT:[extensions]*.EXE;2 the new one.
Drytesting the analysis in a simple test on the CLI-prompt – on both the old and new versions – revealed the dates were 100% equal. Comparing the files reveled NO DIFFERENCES….Something has gone wrong in setting up the environment!

Next, I checked the newly installed version in the Apache environment – and found there were new versions of every extension available, dated on the same date as the PHP and PHPSHR they belonged to: 3-Apr-2008, where the working environment only contained the ECO1 routines, dated 26-Sep-2006. Excepot for the module I built myself, of course.

So I copied all new files, reset the test environment to run the ECO-2 PHP executables, and behold: IT WORKED. So the problem was solved – so far. Next was of course renaming the new versions to become the valid ones, and just test the blog to run. It did – and so I entered this entry using ECO2.

The only problem that might occur is that the MySQL module used is built against the old PHPSHR. Reading the database was found not to cause a problem, and because saving the draft doesn’t moan either. write access is no problem either.

So it might well work. Publishing now….

Update
It does. Good news!

Next: admit the error on ITRC…

What I’ll do in the next update: Keep the PHP environment in the Apache location and run it from there. It would have prevented these problems. Or: In case of a new version, set PHP_ROOT to the Apache installation directory, in case of error change it back to the WASD environment. It means I still need to copy the files form [BIN] and [EXTENSIONS] to the WASD environment BEFORE updating PHP. But that is a way I have walked before.