Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 2 subscribers
  • Views 460 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

7.305 Database problems?

DarKRR
Hello,

on an ASG320 cluster with 1 GB each (active-passive) I experienced massive RAM und swap usage on both machines:
Master: RAM 70%, SWAP 99%
Slave: RAM 81%, SWAP 93%

Approx. 40% of the memory is consumed by tow slon processes. In the system log I find theses messages all the time: 

 2009:07:10-09:00:01 (none) /usr/sbin/cron[17052]: (root) CMD (   /usr/local/bin/reportcontrol.sh)

 2009:07:10-09:00:02 (none) postgres[17062]: [3-1] ERROR:  relation "pfilter" does not exist

 2009:07:10-09:00:02 (none) postgres[17062]: [3-2] STATEMENT:  INSERT INTO pfilter (dayabs, srcip, srccountry, dstip, dstcountry, svc, packets) VALUES ($1,$2,$3,$4,$5,$6,$7)

 2009:07:10-09:00:02 (none) postgres[17062]: [4-1] ERROR:  prepared statement "dbdpg_1" does not exist

[...]

 2009:07:10-09:00:02 (none) ulogd[4684]: pg1: error allocating keyset: Success

[...]

 2009:07:10-09:17:01 (none) /usr/sbin/cron[18485]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)

 2009:07:10-09:17:02 (none) ulogd[4684]: pg1: error allocating keyset: Success

 2009:07:10-09:17:02 (none) postgres[18486]: [3-1] ERROR:  relation "auth" does not exist

 2009:07:10-09:17:02 (none) postgres[18486]: [3-2] STATEMENT:  SELECT dayabs,secabs,int2ip(srcip),username,authresult,facility FROM auth WHERE facility LIKE 'webadmin' AND dayabs

 2009:07:10-09:17:02 (none) postgres[18486]: [3-3]  = 733598 ORDER BY secabs DESC

 2009:07:10-09:17:02 (none) postgres[18486]: [4-1] ERROR:  relation "auth" does not exist

 2009:07:10-09:17:02 (none) postgres[18486]: [4-2] STATEMENT:  SELECT dayabs,secabs,int2ip(srcip),username,authresult,facility FROM auth WHERE authresult LIKE 'failed' AND dayabs

2009:07:10-09:17:02 (none) postgres[18486]: [4-3]  = 733598 ORDER BY secabs DESC

As CPU usage is quite low (around 10%) and only the packet filter and vpn functions are used there isn't a performance problem at present. Do I have to worry about this issue?

Thanks & Greetings
 marc


This thread was automatically locked due to age.
Parents
  • 0
    I'd probably contact support (sounds like you have a commercial license, with you using HA, etc.) about it... they'll probably, in the process, advise you to up2date to 7.404, the DB backend has had significant improvements made to it in the last few versions.  The problem is, is if your DB is messed up now, the problem may not go away with just an up2date, it could get worse until the core issue is eliminated.
  • 0 in reply to BrucekConvergent
    We've had the same issue, and had Astaro Support take a look at it.

    Bottom line (as they explained to me) was that our database had grown too much. By default, the settings for reporting of Acounting, Authentication etc (Reporting -> Settings). are set to be kept for 6 months. Every Day the database is cleaning up and doing maintenance on the database IN MEMORY So if your database grows beyond your memory, swapping will occur. In our case it meant that Astaro Support had to do a cleanup and we had to set the reporting from 6 months to 3 months. For now, this helps.

    I don't know how big your database is at the moment, but if you have a large company with a lote of traffic / users this could be the case.
Reply
  • 0 in reply to BrucekConvergent
    We've had the same issue, and had Astaro Support take a look at it.

    Bottom line (as they explained to me) was that our database had grown too much. By default, the settings for reporting of Acounting, Authentication etc (Reporting -> Settings). are set to be kept for 6 months. Every Day the database is cleaning up and doing maintenance on the database IN MEMORY So if your database grows beyond your memory, swapping will occur. In our case it meant that Astaro Support had to do a cleanup and we had to set the reporting from 6 months to 3 months. For now, this helps.

    I don't know how big your database is at the moment, but if you have a large company with a lote of traffic / users this could be the case.
Children
No Data