Menu
▾
▴
Re: [SL] Apache error running summary reports - reality checking script?
|
From: Michael H. <mh...@it...> - 2008-07-22 17:31:44
|
Just thought I'd post the final resolution to this.
Hadn't gotten it over to a VM yet but needed the reports working
asap so I first updated to the latest and greatest SL, which didn't
fix it, so then I just did a "yum update", did the postgresql 8
upgrade shuffle and hey presto! Reports run instantly like they used
to!
Thanks to all!!!!!!!!
Michael
On Jul 21, 2008, at 10:42 AM, Michael Hasse wrote:
> All valid points except that "top" shows CPU/RAM to be just fine
> while the report is running, as is disk/swap.
> This is an older machine, our last non-virtual system, actually,
> so maybe we'll just go ahead and do the VM migration and see what
> happens.
>
>
> Thanks,
>
> Michael
>
> On Jul 21, 2008, at 8:59 AM, Paul Tammes wrote:
>
>> 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
>>>
>>>
>> ---------------------------------------------------------------------
>> -
>> ---
>> 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
>
>
> ----------------------------------------------------------------------
> ---
> 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
|
