Month: April 2017

First day
Looked into the first (approximately) 24 hours running with the new parameters; not just increased a number of process parameters, but removed some settings required for a number of programs I don’t use anymore, and an increment of page file size (not a requirement but based on minimal values): memory usage (both physical and virtual) have decreased a little from 75% to 50%, but it’s my feeling that mainly due to increased page file sizes.
Paging however, seems the same:

until about 10:00 system time this morning:

It may have to do with PMAS receiving mail, that requires the data to be available. But that has gone on for several hours from midnight, a message per minute; but after about 9:50 messages come in every 5 seconds, so it may well have to do with PMAS – or SYSLOGD writing out messages. Checked the syslogd output – the only available source at the moment – and found the address, residing in Thailand (61.91.54.162) so I blocked it from accessing the network.

(To be continued)

Changed system parameters
Remember I had problems with MariaDB and PHP? I knew there were some changes to be done to the system, and where, but to what values? I asked Mark Berryman (who ported PHP and MariaDB to VMS – so he has some experience in the matter) and he came up with another set of values – in the PQL (Process Quota Limits) area; he has the same type of system as I do (DS10, 2 Gb memory) so I changed my system accordingly: some limits doubled, others tripled in value – which makes sense since the original values come from a 256Gb system….


parameter          old       new
-------------- -------   -------
PQL_DFILLM         128       200
PQL_DWSDEFAULT    2352      6531
PQL_MWSDEFAULT    2352      6531
PQL_DWSQUOTA      4704     13062
PQL_MWSQUOTA      4704     13062
PQL_DWSEXTENT   262144   1280000
PQL_MWSEXTENT   262144   1280000


Since WSDDAULT parameters are not dynamic, I had to reboot.
The result is eminent: the blog runs way faster and smoother; but time will tell whether this is right or needs even more adjustments.
I aloo noted an error in calling MySQL shutwond and startup procedures, and corrected them

Next is a WordPress update 🙂

(Done. Now on 4.7.4)

Next to do is trying PHP 5.4 again, to see whether that stays alive.

Cleanup and configuration changes
First of all, I have started a new accounting file – thought it’s time to do so after 5 years: It takes quite some time to get to the latest data (the file is 256 Mb in size…). Next, I extracted the data of the server-executoree (HTTP%NOBODY) after 01-Jan-2017, to find out what mnay cause the PHP problems. It could be a matter of sizing. It looks like it, and that meant I had to change the working set parameters of this user:

UAF> sho http$nobody

Username: HTTP$NOBODY                      Owner:  WASD Scripting
Account:  WEBSRV                           UIC:    [76,1] ([HTTP$NOBODY])
CLI:      DCL                              Tables: DCLTABLES
Default:  WASD_ROOT:[HTTP$NOBODY]
LGICMD:   LOGIN.COM
Flags:  DisNewMail DisMail
Primary days:   Mon Tue Wed Thu Fri
Secondary days:                     Sat Sun
Primary   000000000011111111112222  Secondary 000000000011111111112222
Day Hours 012345678901234567890123  Day Hours 012345678901234567890123
Network:  ##### Full access ######            ##### Full access ######
Batch:    -----  No access  ------            -----  No access  ------
Local:    -----  No access  ------            -----  No access  ------
Dialup:   -----  No access  ------            -----  No access  ------
Remote:   -----  No access  ------            -----  No access  ------
Expiration:            (none)    Pwdminimum:  6   Login Fails:     0
Pwdlifetime:         90 00:00    Pwdchange:  14-AUG-2012 07:49
Last Login: 14-AUG-2012 07:48 (interactive), 13-APR-2017 19:20 (non-interactive)
Maxjobs:         0  Fillm:       500  Bytlm:       500000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:      2000  JTquota:       4000
Prclm:         100  DIOlm:      1000  WSdef:         1000
Prio:            4  ASTlm:      2000  WSquo:         4000
Queprio:         0  TQElm:       100  WSextent:     20000
CPU:        (none)  Enqlm:       500  Pgflquo:     500000
Authorized Privileges:
  NETMBX       TMPMBX
Default Privileges:
  NETMBX       TMPMBX
Identifier                         Value           Attributes
  WASD_HTTP_NOBODY                 %X8001001D
UAF> mod http$nobody/wsquo=8000/wsextend=30000/biolm=2048/diolm=1024
%UAF-I-MDFYMSG, user record(s) updated
UAF>

That should make at least some difference, time will tell.

Another addition is a job that should tell me about the workload during some time, it may mean I’ll have to do some changes to system parameters and reboot. But this will take a few weeks to set in.

MariaDb test
I had installed MariaDb 5.5, as ported by Mark Berryman. There were two issue with the creation of SSL certificates: The routine wasn’t found where expected, and though all references are to SSL$ROOT:, there is one that refers to SSLROOT (within one of these procedures). Might have been a local issue, and was easily circumvented.
I copied MySQL database using conversion routines, in stead of creating a new one and loading the export (the backup of then database).
One thing to change anyway is the port to listen on: 3306 is currently in use my MySQL 5.1 that is used by the blogs. So I changed this to 3316, and started the server.
Next I connected using mysql -u root -p – entered my password, and could access the data. But at some point, the server crashed, it seems to occur in LIBRTL. This happened three times, same signature (at first glance).

That means contacting Mark Berryman….

Power failure
Around 23:30 (GMT +2) the power broke down in my neigbourhood, just when I was about to call it a day. It lasted for about 40 minutes, as I found out about 4:00. I restarted Diana, found some changes that I still needed to do for the blog logicals, and restart MySQL for some reason, but all seems well now.
One of the changes still there was using PHP 5.4 – which I left for the moment: It seems to do pretty well. So all in all it might well be that it is not PHP causing problems, but MSQL – something I noted earlier; this is a fresh instance and the speed the blog runs on now is remarkable.
Time to switch to MariaDB ?

Weird, though: I have a VT400 as terminal on Diana, all it shows on startup is the banner up to the notion it jumps to the loader – nothing on console on the startup sequence like you normally would get….

(as it turned out: 5.4 does give trouble: this post couldn’t be published, and running the blog gave an error….So I reversed to 5.2)

All the same – and some investigation started.
No surprises.

PMAS statistics for March
Total messages    :   2802 = 100.0 o/o
DNS Blacklisted   :      0 =    .0 o/o (Files:  0)
Relay attempts    :    529 =  18.8 o/o (Files: 31)
Accepted by PMAS  :   2273 =  81.1 o/o (Files: 31)
  Handled by explicit rule
         Rejected :   1488 =  65.4 o/o (processed),  53.1 o/o (all)
         Accepted :    151 =   6.6 o/o (processed),   5.3 o/o (all)
  Handled by content
        Discarded :    364 =  16.0 o/o (processed),  12.9 o/o (all)
     Quarantained :    251 =  11.0 o/o (processed),   8.9 o/o (all)
        Delivered :     19 =    .8 o/o (processed),    .6 o/o (all)


The number of relay attempts was down last months. there were two days with a higher amount (files just over 40 blocks in size), but all the same address (144.217.213.129 – a hosting site in Sacramento (USA)) faking an address in my domain. Since the mail didn’t originate from the inside (and therefore lacks the mail server address) it’s rejected.

18-Mar, between 00:54:42.23 and 00:57:02.37 (145)

26-Mar, between 09:54:58.68 and 09:57:19.61 (150)

A few more but that were single attempts.

WP will be updated this week.

Started examining the reason why PHP 5.3 gives me such trouble, I’ll be evaluating PHP 5.2 performance first to get at least some ide of what is going on in the system when running PHP…