I am running postgresql 7.2.4-5.73, Dual P4, 1GB Ram. The big problem
is that I redirect all internal port 80 traffic to my web server so I
see all traffic whether it is a virus or not and intended for my server
or not. I originally had a problem with running out of memory but I
found a bug in my software that kept the DB connection open so the next
time a new connection was made on top of that. As soon as I removed
that I started getting the processor problem. I am working on patching
my kernel to have the string matching and other new iptables features
to limit the virus traffic but I would like to figure the Processor
problem out as I am working on moving everything to the 2.6 kernel when
RedHat finalizes their release.
I am not familular with many of the logging features of postgres just
the outputing the output to a file instead of /dev/null.
Benjamin
On Jan 6, 2005, at 5:06 PM, Dave Cramer wrote:
> Ben
>
> Well, we need more information
>
> pg version, hardware, memory, etc
>
> you may want to turn on log_duration to see exactly which statement is
> causeing the problem. I'm assuming since it is taking a lot of CPU it
> will take some time to complete( this may not be true)
>
> On your last point, that is where you will get the most optimization,
> but I'd still use log_duration to make sure optimizing the statement
> will actually help.
>
> dave
>
> Ben Bostow wrote:
>
>> I'm still relatively new to Postgres. I usually just do SQL
>> programming but have found my self having to administer the DB now.
>> I have I have a problem on my website that when there is high amounts
>> of traffic coming from one computer to my web server. I suspect it is
>> because of a virus. But what when I notice this, my processor drops
>> to 0.0% idle with postmaster being my highest CPU user. Under normal
>> circumstances the processor runs >90% idle or <10% used. I have tried
>> tuning postgres but it doesn't seem to make a difference, unless I am
>> doing something wrong. If I would like to find a solution other than
>> rewriting all of my SQL statements and creating them to take the
>> least amount of time to process.
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 3: if posting/reading through Usenet, please send an appropriate
>> subscribe-nomail command to majordomo@postgresql.org so that your
>> message can get through to the mailing list cleanly
>>
>>
>
> --
> Dave Cramer
> http://www.postgresintl.com
> 519 939 0336
> ICQ#14675561
>
