Hello Pascal,
thank you for your detailed answer. You are probably absolutely right,
that it is a problem of unsufficiant RAM. The server is a dedicated
machine on wich serveral Projects (mostly not too frequented websites)
are hosted. We can supply RAM to each specific web. We NOW found, that
the ram was limited to 100 MB for the web our problematic shop runs on.
After increasing it to 500 MB the problem seems to be solved. Apache
keep-alive is now set to 1 sec and we have no problems for about two
hours now.
We have access to and played with the params you mention in your second
mail, but nothing helped - not too wondering by having only 100 MB RAM
for the shop. If we find mor about it, or the problem recures, I will
let you know.
So obviously it was not really an oxid-problem but one of human
stupidity ;-)
Thank you very much anyway and sorry for using the list for this.
Best regards, Kai
Am 06.12.2010 14:59, schrieb Pascal Oblonczek:
Hi, Kai,
until you have a good reason, you should reduce PHP memory size to max. 40megs.
256 is far, far too much, don't forget that memory limit is per request!
Ideally, with 110+ Clients you shall reduce it to 22megs (2,5GB RAM / 110).
Don't forget you have overhead per request + Database memory. When RAM fills
up, thrashing may occur at DB level and MySQL ist very sensible to that and may
tear down your whole system. Oxid is quite hungry with RAM. Unfortunately
memory consumption per request scales heavily with number of
categories/manufactures and other core data structures. I guess this is due to
the fact that mostly all views are backwards compatible with old OXID 3 views
where full recordsets have to be loaded upon every request to serve template
variables, no matter if they will be used or not. In OXID 4 getter methods have
been introduced which may lower memory requirements if templates don't request
all core data structures for rendering. Effectively, imagine you have 3gigs
free, divide that by 256, thats 12 (!) clients with full memory allocation and
your setup goes boom.
Finally it is a good idea to user mod_proxy for load balancing. Better you get 100 happy
customers and 10 that get the clue what's going on (sth. like "Shop overloaded,
please check back later") than 110 with random failures.
Mit freundlichen Grüßen,
With kind regards,
Pascal Oblonczek, B.Sc.
_______________________________________________
ELBNAH IT-SYSTEME GmbH
http://www.elbnah.com
Poppenbüttler Hauptstraße 33
22399 Hamburg
Tel: 040 / 55613013
Mobil: 0179 / 2338953
Geschäftsführer: Pascal Oblonczek& Nico Oblonczek
Amtsgericht Hamburg
Handelsregister: HRB 110905
----- Original Message -----
From: Kai Gazmaga
[mailto:[email protected]]
To:
[email protected]
Sent: Mon, 06 Dec 2010 14:22:31
+0100
Subject: [oxid-dev-general] Caching-Problems with a 4.4.3
Hello folks,
I have to maintain an Oxid CE 4.4.3 with some modules on a dedicated
Server with 4 Gigs of Ram. The Server is a managed machine from Webhost
One. I do not find any helpfull hint or answer in the forums. We have
constantly 110+ users in the shop so it is urgent to solve the problem!
Here is the Problem: the shop does not respond in a recuring manor -
every few minutes (maybe 30 or 60), we can not say how often exactly.
The shop starts to slow down until we have no reaction alt all (during a
few seconds). Further requests result in several errors (header already
sent and some others). After about 2 or 3 minutes everything is fine again.
We now found out that we can trigger the phenomenon manually by emptying
the tmp-folder. This results in a lot of apache-processes switching to
deamonized mode. The number increases until we hit the 200 and apache
restarts automatically. After this (or manual restart of apache) the
shop and backend respond normally again. We have 256 MB of RAM for PHP,
MySQL ist running normally and apache does not show other unnormal
behaviour. Switching "keep alive" on and off does not change anything.
Did someone experience something similar or know how to tweek apache or
the shop to solve this problem?
Regards, Kai aka SubNet-One
*Vektor*Design - Web-Programmierung
Kai Gazmaga
Neue Strasse 83
89 073 Ulm Tel.: +49 731 - 3781953
Fax: +49 731 - 3781952
Mail: info (at) vektordesign.de
Web: vektordesign.de
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
