Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 2 subscribers
  • Views 3550 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

No Dashboard statistics

TOHIL
hi guy's

I have a fresh installation of 7.300 with up2date 7.301 and 7.302 applied.

the problem is, i dont have any statics on the dashboard window. all other reporting is working. already tried /var/storage/pgsql/init/reporting_db_init.sh but without success.

do you have any ideas?????


This thread was automatically locked due to age.
Parents
  • 0
    no ideas???????????????????????????????????????
  • 0 in reply to TOHIL
    Hi,

    I have the same problem.
    ASG220  with a fresh installation with up2date 7.302 applied.

    Log partition status:
        Log partition size 0Mb 
        Free space:  0 MB  ...?
  • 0 in reply to vilius
    If you send me the login credentials for SSH/Webadmin access, I'll take a look and see what I can find out. You can use either forum pm or mail to agrosse at astaro dot com.

    Cheers,
     andreas
  • 0 in reply to vilius
    Hi,

    I have the same problem.
    ASG220  with a fresh installation with up2date 7.302 applied.

    Log partition status:
        Log partition size 0Mb 
        Free space:  0 MB  ...?


    OK,
    this problem was a totally different one. You initiated a factory reset, and currently (starting with 7.301) the factory reset is broken - it will remove the reporting data, but not re-create the necessary tables. This bug will be fixed in 7.303. 
    I re-created the reporting database for you, dashboard & inline reporting should work now.
    One additional word of advice: you're running at the limits of the 220, the machine is utilizing 51% of the available swap space, which is detrimental to the performance of the system. I'd suggest either turning off features (ips/imp2p detection comes to mind), or considering upgrading your unit. In any case, please make sure that the reporting database keep times are as short as possible so that database maintenance runs as smooth as possible. Keep an eye on the memory/swap usage during the nightly rotation, too.

    Cheers,
     andreas
  • 0 in reply to andreas
    Hi Andreas,

    Thank you for a great asisstance. 

    Best reagards,
    Vilius
  • 0 in reply to andreas
    Andreas, where is "nightly rotation" documented?  We have only one client where we've tried a cluster.  They have a half-hour of 100% CPU usage every morning at 2:30 - I presume this is the "nightly rotation" phenomenon, or?

    Thanks - Bob
  • 0 in reply to BAlfson
    They have a half-hour of 100% CPU usage every morning at 2:30 - I presume this is the "nightly rotation" phenomenon, or?
    Thanks - Bob


    That is correct. During the nightly 'rotation' (which is not really a rotation, we just called it like that because it works similar to the log rotation) data is aggregated and written into archive tables. This keeps the performance from degrading for calls which do run exclusively on today's data (like all the inline reporting stuff & the dashboard).
    Since it is run with the lowest possible priority, it will peg the CPU for a while but won't disturb any other process running. 

    Cheers,
     andreas
Reply
  • 0 in reply to BAlfson
    They have a half-hour of 100% CPU usage every morning at 2:30 - I presume this is the "nightly rotation" phenomenon, or?
    Thanks - Bob


    That is correct. During the nightly 'rotation' (which is not really a rotation, we just called it like that because it works similar to the log rotation) data is aggregated and written into archive tables. This keeps the performance from degrading for calls which do run exclusively on today's data (like all the inline reporting stuff & the dashboard).
    Since it is run with the lowest possible priority, it will peg the CPU for a while but won't disturb any other process running. 

    Cheers,
     andreas
Children
  • 0 in reply to andreas
    Andreas, in the attached, there's an initial 100% usage from 02:30 to 03:00, then three more half-hour sessions at 03:30, 04:15 and 06:45.  The first person comes to work at 07:30.

    Do you interpret the 100% usage after the first half hour as a continuation of the 'rotation'?  If so, is that an indication that the unit is too busy?

    Thanks - Bob
  • 0 in reply to BAlfson
    That's hard to guess just by the looks of the graph. You can take a look in the system.log logfile, as long as the rotation stuff is running there should be log entries like this:

    2008:10:20-02:30:03 (none) system: websec_aud log rotation starting
    2008:10:20-02:30:03 (none) system: websec_aud log rotation finished
    2008:10:20-02:30:03 (none) system: websec_aud rotation took 0 seconds to complete

    At 6:40, the database maintenance is starting - this deletes entries from the database depending on the settings that you configured in Reporting->Settings in the WebAdmin. This would explain at least the spike at 6:40. 

    Cheers,
     andreas