Menu
▾
▴
Re: [SL] Apache error running summary reports - reality checking script?
|
From: Paul T. <pt...@wa...> - 2008-07-21 15:59:55
|
Seeing FC4 where 9 is out, postgresql 7.4 where 8.x is out, could it be the hardware is old as well? I know, if it ain't broke and all that ;-) If the hardware is not up to speed for a larger number of months, memory overflow combined with swapping to (slow/old/olmost dead?) Harddisk comes to mind. The change in response between say an AMD Duron 800 and AMD 4450e dualcore is stunning. Both el cheapo cpu but frome different era's alltogether: in hardware 8 years is a lifetime and a halve. Nice part: the power consumption of some modern cpu's like 4450e ore dulcore intels is stunningly lower. So that kind of investment earns itself in a few years time as well. (If that is too much of an investment, try adding some extra memory to the old box. SD-ram is still available in some antique shops, or second hand on computer user club trade fairs. DDR (sec) is more readilly available, and other than SD-ram (which is rare, therefore expensive) pretty cheap as well Hth 2008/7/21 Michael Hasse <mh...@it...>: > Further testing shows that it is indeed something timing out. The > reason the test company report ran okay was because there were hardly > any records. I am also able to run the problem reports okay provided > I choose only a month or two range. Having run the reports for > successive months of the entire year with no problems we can at least > get the taxes taken care of, (whew! :), and short of some bizarre > boundary error this should prove that the data is okay. > > But the question remains of what exactly it is that is timing > out...? > > In the process of testing this it looks like we actually get any > of a variety of errors, some of them pretty generic, e.g. plain old > Apache "Internal server error". > (William's suggestions earlier unfortunately did not pan out.) > > This is an FC4 box running: > Apache 2.0.54 w/mod_perl 2.0.1 > Postgresql 7.4.13 > Perl 5.8.6 > > Any ideas? > > > Thanks! > > Michael > > > ================================ > Based on the advice to check dates I've just been through every date > value of every record of every table, and I found a couple of bogus > dates, (you'd think bounds checking would catch '08-27-0200'), and > fixed them, but still no go. > I also checked to see if maybe the version upgrade had missed a > file due to permissions or something but all the .pl files are the > same date and perms, (except setup.pl is a few days newer but that's > to be expected and shouldn't matter). > What other things should we be checking? > Mismatches between invoices and line items, (e.g. line items > without invoices)? > > <rant> > I'm really surprised there are no scripts already written for > this. I actually was a rocket scientist, ahem, database programmer, > in a past life and every project I ever worked on had an "admin > toolkit" by the end of it with various queries to be sure nothing > bizarre had slipped through the cracks. This wasn't intentional, but > all db programmers end up doing some "pre-QA" of their own and the > scripts just grow naturally from that. > </rant> > > Anyway, again, suggestions would be greatly appreciated from > anyone who has dealt with anything like this before...? > > > Thanks!!!! > > Michael > > > > On Jul 3, 2008, at 4:06 AM, ja...@in... wrote: > > > A simple sanity check that I wish I had time to implement is to > > regularly (cron job) : > > Check each company in the database and hunt for any transactions > > with illogical (ie stupid) dates > > such as 07/03/2080 (transposed year digits) > > Send informative email to user who entered the offending > > transaction, and copy to sysadmin. > > Still hoping Dieter might implement something sensible in company > > defaults to solve this simple problem. > > Been mentioned before. > > Very interested in any other sanity checks. > > DJ > > On Thu 03/07/08 3:21 PM , Michael Hasse mh...@it... sent: > > Months later, I'm getting back to this, (prodded by tax deadlines of > > > > course! :) > > I did check the timeout directive and raised it to some > > ridiculous level to no avail, (and same duration of wait so I don't > > > > think that's it). > > Also don't think it's a record count issue as it was working > > fine > > right up a month or two before the upgrade and we don't do THAT much > > > > business. > > I also opened a terminal session to the host server and watched > > > > the stats as it was running and there were no issues with > > memory/swap/ > > etc running out or anything like that. > > Somebody suggested checking another company in the system, (good > > > > idea, my apologies for not doing that before posting! Brain > > fade...). > > Unfortunately that company works just fine so I have to assume > > at > > this point that I have a corrupt record somewhere/somehow. > > So now the question is - are there any sort of scripts that can > > > > be run to do a sanity check? Has anybody had to deal with bad > > records and might have some tips to save a few hours of poring over > > > > the DB structure? > > Thanks!!!!!!!!!!!! > > Michael > > On Jan 8, 2008, at 6:01 AM, William McKee wrote: > >> On Mon, Jan 07, 2008 at 09:34:39PM -0800, Michael Hasse wrote: > >>> Just an update on this. Permissions are all fine and the reports > > run > >>> with no problems in our test company. Reading up a bit on the > > errors > >>> it looks like a simple timeout problem where Apache is giving up > > on > >>> the script before it finishes due to the amount of data we have > >>> slowing the script down. (System resources are okay so we're not > > > >>> running out of memory or anything). > >> > >> Interesting, I hadn't considered timeout error causing that > > message. > >> > >> > >>> Suggestions/advice are welcome and we'll keep plugging away > > at it > >>> and post back if we figure it out. > >> > >> Have you checked out the TimeOut directive[1]? I've seen some > > people > >> comment the TimeOut does not affect CGI scripts, but Apache > > security > >> tips[2] say the following: > >> > >> "As TimeOut is currently used for several different operations, > > > >> setting > >> it to a low value introduces problems with long running CGI > > scripts." > >> > >> I've seen others suggest using FastCGI. Keep us posted on your > >> progress. > >> > >> > >> Good luck, > >> William > >> > > ---------------------------------------------------------------------- > > --- > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source project, > > along with a healthy diet, reduces your potential for chronic lameness > > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > _______________________________________________ > > sql-ledger-users mailing list > > sql...@li... > > https://lists.sourceforge.net/lists/listinfo/sql-ledger-users > > > ------------------------------------------------------------------------ > - > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > sql-ledger-users mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sql-ledger-users > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > sql-ledger-users mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sql-ledger-users > > |
