• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

(Apache/PHP/MySQL related) Looking for info on PROCESSES= config.sys statement

Started by RobertM, 2010.04.12, 21:45:07

Previous topic - Next topic

RobertM

Quote from: Fahrvenugen on 2010.04.22, 05:53:23
You can definitely try looking for DLL's, if you have multiple versions of the same DLL on your system this might be part of it. 

I do wish we had a PHP module (or a way to make PHP work reliably) with LDGW, and the ability to add some of the Apache features (such as the URL re-writing stuff) to LDGW.  LDGW is a great web server, unfortunately it never seemed to get the recognition it deserved.



I wish I had the time to learn the GWAPI stuff... I've got a copy of VAC++ v3 just sitting here begging for such use.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Ben

Quote from: RobertM on 2010.04.21, 18:31:44
Hi Ben,

That may indeed be helpful. If you could check on one other thing for me... what version (or filesize or other version indicator) is the LIBC063 DLL on your system?

Since MySQL seems part and parcel to my problem on the Apache system - yet exhibits no problems on the SMP system... I think (assuming it's not the version of LIBC063 on the Apache system - or the way it acts on SMP vs UNI) that maybe you are on to something.

Any and all version numbers (Apache, PHP, MySQL, LIBC063 - or anything else you think relevant) would be greatly appreciated.

Server Version: Apache/2.2.15 (OS/2) PHP/5.2.13
Server Built: Mar 7 2010 09:01:34

DB Type: mysql
DB Version: 5.1.36

LIBC063:      1,349,060   6/11/2007

SMPKernel:    908,650    6/15/2007

ACPI:               247,182  10/02/2008

I hope that helps.

Any more questions feel free to ask.

If I think of anything additional I'll post that too.


RobertM

Thanks Ben...

Seems I have some upgrading of PHP and MySQL and Apache to do... LIBC063 is same size, and no other versions on the system.

In the meantime, I think I will try killing MySQL (using MySQLADMIN shutdown) at the same time I kill and restart Apache. The key again is to ensure that both restart in different processes to free memory and other resources. I've got it currently set at a 6 hour restart loop.

Of course, the bad thing is that means all caches are purged... but I can live with that if it "resolves" things until I do the updates and test that.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

Well, so far this is the longest I have went without Apache or MySQL crashing - so the workaround seems to be working. Now... on to some upgrading to see what happens.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Fahrvenugen

So just to confirm if I understand correctly, you've got a REXX script that:

1.  Kills MySQL using Mysqladmin shutdown
2.  Kills Apache with the apache shutdown script (which just kills the PID
3.  Restart Apache
4.  Restart MySQLD

Or are you restarting Apache and MySQL in the swapped order?

I'm guessing this is all in a REXX script called from one of the many schedulers out there.

I'm asking, I'd love to try this on the troublesome website that I have (the one I had to move off of OS/2) to see if I can get it running reliably under Warp.  I could potentially eliminate one machine (a machine which - its only task right now is to serve this troublesome wordpress website - overkill for a single machine, but it was the easiest way to get things up and running at the time...  as it is that machine requires a reboot every 2 - 3 weeks)

mobybrick

Hi,

The problem is likely due to with problems in the low-memory arena. Many of the LIBC063 calls, in particularly PHP5, consume large amounts of low memory.

In one PHP5 app, I can exhaust OS/2 Apache2/PHP5/MySQL/LIBC063 in a single request. The request consumes 300Mb of low memory, and then exhausts with a weird error - sometimes a SYS3171 - but usually a LIC063 exception - but Thecus shows the shared memory arena as reaching 64Kb free and then PHP5 dies. On Win the calls run fine and consume 600Mb of RAM - but OS/2 can't allocate this and dies :( even on a 4Gb system.  As soon as exception occurs, the shared memory reverts to being free.

Under Win32 and Linux, PHP5 can routinely use 4-700Mb of RAM on busy systems - something we can't give it. Under OS/2, setting the PHP max memory limits aren't the problem as it is OS/2 that runs out memory.

Updating the PHP5/MySQL/Apache2 builds doesn't really help - remember, that even the order of things started in the startup.cmd can affect the amount of low memory available in the shared memory arena.

With some of the situations described above, it isn't how many concurrent threads or web sockets that are the problems per see, it is how much shared memory is being used - i.e. many clients can be supported if they use little memory, but few (or one) clients can be supported if that single request uses a lot of shared memory.

kLIBC, IMHO, needs re-working to make most of its calls use high-memory. Simply marking LIBC063.DLL to loadhigh doesn't working because all of the compiled apps that use the library need re-compiling AFAICS.

This needs fixing soon as soon the 300Mb of shared memory (its actually 512Mb, but 300Mb or so is all that is left once the system is booted to the desktop on most systems) is going to become a big problem.

Regards,
Moby.

Fahrvenugen

Moby,

Thanks for the potential reasoning behind what is happening.

I guess my question is:  If it is a PHP / MySQL / Libc thing, then how come the same PHP based app can run fine when used on Dink's Web/2 using the PHP CGI exe, but fails / crashes on Apache2?

Of course, the main need for Apache is more advanced features (such as URL re-writing for SEO, etc) which Web/2 can't do.  But if it was purely a memory thing with PHP and MySQL grabbing huge amounts of low / shared memory, then I'd expect to see similar problems there.

Of course it is true that Web/2 doesn't use Libc063, so that might be part of it - just one more app (Apache) using Libc takes up too many resources.  I don't know.

Thanks

RobertM

I have some thoughts on this.

First, it's not just that LIBC063 exhausts the low memory arena on a single request (that isn't my problem). It also seems that (whether by design or by accident) under certain circumstances (for instance, when in use by Apache/MySQL/PHP) it does not clean up used memory.

That seems to be evidenced by the fact that under at least my setup, it's not a single large memory request causing the issue (that has never happened yet under my setup), but a collection of smaller ones over time that cumulatively exceed the available memory in the low memory arena. Otherwise, my "workaround" would not have alleviated my problem.

That's further evidenced by the fact that on my setup, no single request causes it. I can start a fresh copy of everything after a fresh boot and perform ONE certain medium sized (memory allocation wise) request with no problems. If the server is running half a day though, and I try the exact same single request with little to no activity on the server, things start to crash because of resource depletion.


So, perhaps the situation is some aspect of how Web/2 serves requests is different than the way Apache does. My guess is that Web/2 serves each in it's own process, and thus is freeing what memory is being used by LIBC063 upon the process's completion; while Apache perhaps is serving them all in one process via multiple threads, and thus not freeing the resources between requests until eventually the memory resources are depleted.


IF that theory is correct, that would mean that two things would need to happen... (1) LIBC063 would need to be recompiled to utilize the high memory calls implemented in WSeB and Warp 4 with the appropriate FPs, and (2) the more difficult part - something would need to be done to ensure that memory was freed at the completion of each call by a thread.

But again, that's based on my speculation on how Apache and Web/2 may be doing things differently than each other - which, not knowing enough about the underpinnings of either, I may be way off base.

Best,
Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

Quote from: Fahrvenugen on 2010.04.24, 20:02:17
So just to confirm if I understand correctly, you've got a REXX script that:

1.  Kills MySQL using Mysqladmin shutdown
2.  Kills Apache with the apache shutdown script (which just kills the PID
3.  Restart Apache
4.  Restart MySQLD

Or are you restarting Apache and MySQL in the swapped order?

The key being first, that I have selected a time limit that is under the amount of time it takes for them to crash on my system (in my case 6 hours works... I could probably get away with 10-12 hours, but due to search engine activity, that seems chancy).

Then I:

1. Have two REXX scripts:
--(a) One that starts MySQL in it's process
--(b) One that spawns Apache in a separate process from itself

2. The Apache script (since it is free as soon as it spawns Apache) waits 6 hours then (in a separate spawned process space) kills Apache (using the shutdown.cmd script, with some changes in the paths of the statements in it to ensure it finds what it needs)

3. The Apache Script then kills MySQL by calling MySQLAdmin shutdown in a separate process.

4. The MySQL script regains control once MySQL terminates. To ensure resources are freed, it spawns a new process and loads itself. The new process of that script then restarts MySQL (Step 1a)

5. The Apache script spawns a new process which loads the same Apache script which spawns another process where Apache starts (Step 1b)

6. The original scripts exit and close.

Not the neatest, and I can clean it up a little I am sure... but as long as my sleep value is small enough, it works as each original process is always killed, closed and resources freed (via killing and closing).

Quote from: Fahrvenugen on 2010.04.24, 20:02:17
I'm guessing this is all in a REXX script called from one of the many schedulers out there.

Yes it's all in a couple REXX scripts, and no, it doesnt use any of the schedulers out there... the ones I have found seem dependent on LIBC063 and thus dont solve the problem. It simply calls SysSleep(SLEEPTIME) and spawns new copies of itself.

Quote from: Fahrvenugen on 2010.04.24, 20:02:17
I'm asking, I'd love to try this on the troublesome website that I have (the one I had to move off of OS/2) to see if I can get it running reliably under Warp.  I could potentially eliminate one machine (a machine which - its only task right now is to serve this troublesome wordpress website - overkill for a single machine, but it was the easiest way to get things up and running at the time...  as it is that machine requires a reboot every 2 - 3 weeks)


I can send you the scripts if you want. They are very simple. And as I said, I am sure that they can be done better. They are not done better currently because originally, it was one script that killed and restarted Apache... and once I realized that did not solve the problem, I cobbled on the functionality to kill and restart MySQL and created the MySQL script. My priority at the time was to get the site working as quickly as possible - as opposed to creating a polished set of scripts.

Best,
Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


mobybrick

Quote from: RobertM on 2010.04.25, 01:31:14
First, it's not just that LIBC063 exhausts the low memory arena on a single request (that isn't my problem). It also seems that (whether by design or by accident) under certain circumstances (for instance, when in use by Apache/MySQL/PHP) it does not clean up used memory.

That seems to be evidenced by the fact that under at least my setup, it's not a single large memory request causing the issue (that has never happened yet under my setup), but a collection of smaller ones over time that cumulatively exceed the available memory in the low memory arena. Otherwise, my "workaround" would not have alleviated my problem.

That's further evidenced by the fact that on my setup, no single request causes it. I can start a fresh copy of everything after a fresh boot and perform ONE certain medium sized (memory allocation wise) request with no problems. If the server is running half a day though, and I try the exact same single request with little to no activity on the server, things start to crash because of resource depletion.

So, perhaps the situation is some aspect of how Web/2 serves requests is different than the way Apache does. My guess is that Web/2 serves each in it's own process, and thus is freeing what memory is being used by LIBC063 upon the process's completion; while Apache perhaps is serving them all in one process via multiple threads, and thus not freeing the resources between requests until eventually the memory resources are depleted.


Possibly, but I have an alternative theory on this. You will need to use Theucus to confirm it, however.

Firstly, Web/2 uses a single process for webserving - it's Apache2 that uses multiple processes. I suspect that Apache2 simply gives you another 50Mb of working space in the shared memory arena, so the system will last long.

What's happening over time is that I suspect that the bits of memory that Apache uses for working memory (remember, Apache spawns a new process, a 'fork' for each client) and this grows over time as clients are serviced. These will use more memory and this is fine. They might leak memory, but I have not seen it. What does happen though is that the shared memory arena becomes fragmented - OS/2 can't find enough *contiguous* memory in the shared arena for a large request. So your large request fails at the end of the day because the shared memory is a mess - used by a DLL, LIBC063, which never drops out memory but is constantly alloc/freeing memory - there might (or not) be a leak, but the biggest chunk of free memory becomes too small.

The fixes are this are twofold, IMHO

1. Building LIBC063 so that apps use high memory
2. Building apps with static linking under GCC - reducing reliance on a shared DLL in memory. Whether or not this is feasible I don't know - but it would appear to solve other problems IMHO.

We need to start  bounty to get some work done on kLibC as there have been no updates for a while. Getting some of the memory issues sorted, plus some of the bugs, and even maybe full support for pthreads would be very desirable.

Regards,
Moby

RobertM

Quote from: mobybrick on 2010.04.25, 01:50:09


Possibly, but I have an alternative theory on this. You will need to use Theucus to confirm it, however.

Firstly, Web/2 uses a single process for webserving - it's Apache2 that uses multiple processes. I suspect that Apache2 simply gives you another 50Mb of working space in the shared memory arena, so the system will last long.

...

Regards,
Moby

Ooops... I got the situation backwards. I thusly prefer your theory. Sadly, on one of my boxes (the Netfinity 7000 M10), Thesues will not run. I havent yet tried it on the other box, and cant afford to take that box down for any length of time.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM

So... it seems that Apache isnt always killed, but MySQL is... and that seems to alleviate problems.

Anyway, I am working on adding the use of one of the REXX memory monitoring DLLs, to allow restarting once the low memory arena starts to drop in memory.

Once I am done, I will post the scripts...


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


RobertM



The script:
- I need to kill Apache from within the running script (not enough resources to kill it by spawning a new process)
- I'm finding MySQL seems to be the bigger problem - once it is killed and restarted, a ton of resources seem to be freed.
- Digging for the REXX Extension DLL that reads available memory - I think it was RXU... I will find it and see what I can do with that.


So... soon I will have something up...


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


mobybrick

Interesting... but the script will need to make sure that MySQL is shut down nicely or db corruption could occur (or transactions borked)... but I guess you already thought of this :)

Look forward to see what you get cooked up. Doesn't solve my problems tho where one or two big requests need 3-400Mb of memory - and OS/2 can never provide it...

RobertM

Quote from: mobybrick on 2010.04.29, 00:54:54
Interesting... but the script will need to make sure that MySQL is shut down nicely or db corruption could occur (or transactions borked)... but I guess you already thought of this :)

Yup. It uses MySQLAdmin shutdown to perform an orderly shutdown.


Quote from: mobybrick on 2010.04.29, 00:54:54
Look forward to see what you get cooked up. Doesn't solve my problems tho where one or two big requests need 3-400Mb of memory - and OS/2 can never provide it...

Nope sadly it doesnt. Seems we need a few things... libc063/Apache/MySQL/PHP recompiled to make use of the new high mem calls, and something that can make free memory contiguous.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|