Excessive wa% (disc access) e.g. deleting attachements

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • charlesr
    Senior Member
    • Jan 2008
    • 176
    • 4.2.X

    [Forum] Excessive wa% (disc access) e.g. deleting attachements

    My server regularly falls over. I'm on a vps package that is supposed to support 600 online users. It has 1.1m posts and normally around 100 users.
    Slow query log suggests search is the problem (normally a search query is the first one to go slow e.g. 200+ just before the server goes mental with 100+ load....)

    It's v4.1.5 and I run with very few basic plugins and all the intensive options in vb are turned off out of necessity.


    I have had the search facility on the forum turned off since yesterday.

    This has allowed me to see if anything else is causing the problem or if it's just intensive search.

    I have taken a couple of screenshots from "top" (see attached)

    The first one is just normal forum activity, albeit seeming a bit slow - see attachment "Top(withSearchTurnedOff).gif"
    In this shot you can see that cpu is barely registering but "wait" (disc access) is maxed out.
    Later at the start of typing this message, I had a look and wait is similarly high (would make a similar screenshot).

    At the end of typing this message, wait had dropped off (but still jumps around between 0 and 50%)



    That's not good is it?

    The next one called "Top(Delete6LargestAttachments).gif" shows an attempt to delete 6 attachments via vbulletin's admin panel.
    Firstly in vbulletin admin: "View largest attachments" - this takes 10 seconds to show 10 attachments. Again the cpu is doing nothing and wait is maxed. (There are 4000 attachments to search through - not that many I think).
    Then of the top 10, I selected 6 and asked it to delete them. I would have thought that this would have been a fairly quick task - delete 6 files and send 6 updates to the database accordingly (the attachments are stored in the filesystem, not the database by the way).
    However it took around 20 seconds. This is repeatable.
    Again, the CPU is doing very little and the everything is just waiting for the disc.

    I'd expect the answer here would be "hosts fault", but perhaps someone has a suggestion for something I can check to confirm where the issue might stem from (e.g. I/O problems or vbulletin/database problems).

    Thanks!

    Finally in the past hour, even with search turned off, I've had 10 queries appear in the slow query log.
    For example
    # Time: 110901 12:40:52
    # Query_time: 24 Lock_time: 0 Rows_sent: 1 Rows_examined: 14191
    SELECT post.postid
    FROM post AS post

    WHERE post.threadid = 34853
    AND post.visible = 1
    AND post.userid NOT IN (3472,11,4180)

    ORDER BY post.dateline
    LIMIT 14190, 10;

    Is this a normal amount of queries to be appearing in the slow query log? The queries don't seem to be very exciting.
    Attached Files
    http://www.bordersdown.net - 10 years of videogame reviews and chat
  • Trevor Hannant
    vBulletin Support
    • Aug 2002
    • 24358
    • 5.7.X

    #2
    As you are on a VPSserver I would advise that you request server optimization help by starting a thread in the Server Configuration forum supplying the information requested in this thread:

    Vote for:

    - Admin Settable Paid Subscription Reminder Timeframe (vB6)
    - Add Admin ability to auto-subscribe users to specific channel(s) (vB6)

    Comment

    • Freezerator
      Senior Member
      • May 2002
      • 574
      • 3.6.x

      #3
      How fast is your VPS disk? Because if your on a simple sata raid array or worse a slow SAN then you can experience slow I/O if there are many more VPS using the same storage platform simultanious. Try some disk benchmarks, especially on your access time.

      Like this tool seeker: http://www.linuxinsight.com/how_fast_is_your_disk.html (don't forget to chmod +x when trying to run)

      You will get some results like this:

      My SAS 15k raid10 array
      Code:
      [EMAIL="root@tank"]root@tank[/EMAIL] [~]# ./seeker /dev/mapper/VolGroup00-LogVol00
      Seeker v2.0, 2007-01-15, [URL]http://www.linuxinsight.com/how_fast_is_your_disk.html[/URL]
      Benchmarking /dev/mapper/VolGroup00-LogVol00 [274528MB], wait 30 seconds..............................
      Results: 184 seeks/second, 5.42 ms random access time
      My SAN raid10 array with 14 sata disks:
      Code:
      [EMAIL="root@apoc"]root@apoc[/EMAIL] [~]# ./seeker /dev/mapper/VolGroup00-LogVol00
      Seeker v2.0, 2007-01-15, [URL]http://www.linuxinsight.com/how_fast_is_your_disk.html[/URL]
      Benchmarking /dev/mapper/VolGroup00-LogVol00 [4224MB], wait 30 seconds..............................
      Results: 122 seeks/second, 8.16 ms random access time
      Last edited by Freezerator; Thu 1 Sep '11, 4:44am.
      Dutch vBullletin users social group!

      Comment

      • charlesr
        Senior Member
        • Jan 2008
        • 176
        • 4.2.X

        #4
        Here are my results. How good or bad are they?

        Code:
        # /sbin/hdparm -t /dev/xvda2
        
        /dev/xvda2:
         Timing buffered disk reads:   48 MB in  3.07 seconds =  15.65 MB/sec
        Code:
        # ./seeker /dev/xvda2
        Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
        Benchmarking /dev/xvda2 [15257MB], wait 30 seconds.............................
        Results: 107 seeks/second, 9.34 ms random access time
        http://www.bordersdown.net - 10 years of videogame reviews and chat

        Comment

        Related Topics

        Collapse

        Working...