Re: [WebDNA] WebDNA7 and mod_fcgi
This WebDNA talk-list message is from 2013
It keeps the original formatting.
numero = 110575
interpreted = N
texte = +1 /Palle On 17/08/2013, at 09.09, John Butler
= wrote: > yes, it *feels* like that (what Chris says) to me too - some (legacy?) = code somewhere eats too much RAM (near the limit) .. which Webdna does = not recover from well ... and so Webdna stays in that limited-RAM state = (*even though* RAM should have meanwhile been freed up again; the = offending script has long since stopped parsing). I bet there is some = bad code in the Webdna engine itself ... that does not do "garbage = collection" properly... does not re-free up RAM that was used, under = certain conditions ... and when our scripts get near the hardware RAM = limit, then this weakness, in the heart of Webdna, gets uncovered. I = have been watching this behavior, off an on, since the late 1990's. >=20 > Rebooting fixes it, until the situation it repeated. >=20 > It does not have to occur when Webdna has been up a long time.. the = situation can be repeated within a minute of rebooting.. if a = too-RAM-intensive script it parsed again. >=20 > Assuming my intuition is accurate, I think that without ability to fix = the real issue inside Webdna, our best bet is to prevent our scripts = pushing the envelope too much, in RAM. >=20 > I don't know anything for sure.. but what I type here is my BEST = intuition on the topic ... repeatedly, over the years. >=20 > -Govinda >=20 > On 2013-08-17, at 2:55 AM, christophe.billiottet@webdna.us wrote: >=20 >> According to these two errors pointing at mod_fcgid, i would suggest = to restart apache or reboot the whole server: the memory footprint of = the server has probably increased because of a long uptime period. A = simple reboot should fix it. WebDNA.fcgi itself is not involved in this = error. >>=20 >> - chris >>=20 >>=20 >>=20 >>=20 >> On Aug 16, 2013, at 11:07 PM, Dan Strong wrote: >>=20 >>> Apache error logs littered with these two errors (15000+/day): >>>=20 >>> 1) [warn] (103)Software caused connection abort: mod_fcgid: = ap_pass_brigade failed in handle_request function >>> 2) [notice] mod_fcgid: too much /var/www/html/domain.com/page.html = process(current:1, max:1), skip the spawn request >>=20 >=20 > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us
Associated Messages, from the most recent to the oldest:
+1 /Palle On 17/08/2013, at 09.09, John Butler = wrote: > yes, it *feels* like that (what Chris says) to me too - some (legacy?) = code somewhere eats too much RAM (near the limit) .. which Webdna does = not recover from well ... and so Webdna stays in that limited-RAM state = (*even though* RAM should have meanwhile been freed up again; the = offending script has long since stopped parsing). I bet there is some = bad code in the Webdna engine itself ... that does not do "garbage = collection" properly... does not re-free up RAM that was used, under = certain conditions ... and when our scripts get near the hardware RAM = limit, then this weakness, in the heart of Webdna, gets uncovered. I = have been watching this behavior, off an on, since the late 1990's. >=20 > Rebooting fixes it, until the situation it repeated. >=20 > It does not have to occur when Webdna has been up a long time.. the = situation can be repeated within a minute of rebooting.. if a = too-RAM-intensive script it parsed again. >=20 > Assuming my intuition is accurate, I think that without ability to fix = the real issue inside Webdna, our best bet is to prevent our scripts = pushing the envelope too much, in RAM. >=20 > I don't know anything for sure.. but what I type here is my BEST = intuition on the topic ... repeatedly, over the years. >=20 > -Govinda >=20 > On 2013-08-17, at 2:55 AM, christophe.billiottet@webdna.us wrote: >=20 >> According to these two errors pointing at mod_fcgid, i would suggest = to restart apache or reboot the whole server: the memory footprint of = the server has probably increased because of a long uptime period. A = simple reboot should fix it. WebDNA.fcgi itself is not involved in this = error. >>=20 >> - chris >>=20 >>=20 >>=20 >>=20 >> On Aug 16, 2013, at 11:07 PM, Dan Strong wrote: >>=20 >>> Apache error logs littered with these two errors (15000+/day): >>>=20 >>> 1) [warn] (103)Software caused connection abort: mod_fcgid: = ap_pass_brigade failed in handle_request function >>> 2) [notice] mod_fcgid: too much /var/www/html/domain.com/page.html = process(current:1, max:1), skip the spawn request >>=20 >=20 > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us
Palle Bo Nielsen
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
WC2.0 Memory Requirements (1997)
Robust WebDNA Job Manager / Accountant (2006)
Message Boards (2003)
Sorting search results (1998)
WebCat2b15MacPlugin - showing [math] (1997)
WebCatalog 2.0 b 15 mac (1997)
Nested vs conditional (1997)
WebCatalog for Postcards ? (1997)
b12 cannot limit records returned and more. (1997)
Appending Record Prob (2001)
Version 2.0 and 1.6 simultaneous (1997)
Nav. 4 probs with cart - Serious problem (1997)
Post (1997)
WebCat Documentation (was [platform] tag?) (1998)
This list needs a digest: rant, rave... (1997)
Emailer (1997)
followup to ws3 vs ws2.1 speed (1998)
Custom WebCat Prefs ... (1997)
Hiding HTML and page breaks (1997)
checking for [ and ] in form fields ... (1997)