1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

XenForo uses more server resources after conversion

Discussion in 'XenForo Questions and Support' started by htdesignz, May 29, 2011.

  1. htdesignz

    htdesignz Active Member

    Our forum was converted from vBulletin to XenForo. It is running on a private server. In fact, after the conversion, I realize that XenForo uses up more server resources than vBulletin. Do you have any solutions to help us optimize our server to run XenForo better? Our forum is big. It has more than 170,000 members and 4 million posts.
     
  2. Wuebit

    Wuebit Well-Known Member

    Stats? how much more and more what? its ok saying resources but there are tons of resources which ones?
    Some more info wouldn't go a miss.
     
  3. Brogan

    Brogan XenForo Moderator Staff Member

    Based on all other feedback I've seen, the opposite would seem to be true.

    As Vodkaholic says, some server spec's, details, and before and after data would be useful.
     
  4. Nasr

    Nasr Well-Known Member

    With that many posts, I think you'r disk space will have increased triple if not quadruple the size Vbulletin was. The search index is the main reason for this. Kier has stated they have something planned for big boards with version 1.1 to help remedy that issue.
     
  5. Mike

    Mike XenForo Developer Staff Member

    More information is definitely required. "Resources" doesn't tell me much - load? CPU? disk space? I/O in general? If it's a CPU/load related, then some info on things like search would be important. Search is never going to be fast with 4 million posts; it's just a limit of MySQL.

    I should also note that if you have a big board and you tuned MySQL, you probably didn't tune any of the InnoDB settings (as you likely weren't using it). That would be a good thing to modify.
     
    Darkimmortal likes this.
  6. estranged

    estranged Well-Known Member

    As Mike said I suggest tuning innodb settings. innodb_buffer_pool_size is the most important one and if you have enough ram you can set it as the same size of your innodb data. It will decrase load but make sure you have enough ram because if your server starts swapping, things may get even worse.

    https://github.com/rackerhacker/MySQLTuner-perl

    This tool may help you.
     
  7. Jake Bunce

    Jake Bunce XenForo Moderator Staff Member

  8. htdesignz

    htdesignz Active Member

    This is our server specs: 2xE5620, 10Gb Ram, 4x250Gb HDD raid 10
    Our database is about 7GB.
    We've been facing MySQL crashes lately. And in XenForo, what affects MySQL most?
     
  9. kforo

    kforo Active Member

    Did you use sphinx before, or currently for your site search?
     
  10. htdesignz

    htdesignz Active Member

    I use XenForo default search.
     
  11. User

    User Well-Known Member

    I think those numbers are pretty misleading. If you consider a vB install that's been around for a while there will be tons of add-ons running providing functionality that doesn't even exist in XF. Naturally that functionality comes at the expense of more queries/resources. I don't think anyone will dispute that XF is more optimized than a script that has been extended for like a decade, it's just important to keep things in perspective.
     
  12. Mike

    Mike XenForo Developer Staff Member

    InnoDB tuning will be very important, as will getting off of MySQL full text search.
     
  13. kforo

    kforo Active Member

  14. Rudy

    Rudy Well-Known Member

    I'm looking at this forum right now to get a few specs. Just to put things into perspective, I'm running our vB3 "big board" forum with 700+ users online during peak hours (5 million posts), 4GB memory, and a server that is about 2-1/2 years old with an Intel Core2 Duo CPU. It is not as fast as something newer (we are eligible for a free server "refresh" actually), but it churns along reliably without having any major slowdowns. We do use APC for PHP opcode caching, and run Sphinx for the search, and have some other minor tweaks in place...but if this subject forum has lower traffic, then I'd agree with everyone that MySQL probably needs tuning and the addition of some other tweaks would probably help things substantially.

    When I first took over the big board several years ago, our host only had a Celeron processor in their lowest dedicated server, and the first thing that killed us was that we were using the default my.cnf (MySQL configuration). Once I hooked up with vB, who offered several suggested new settings, the bottleneck cleared up. Changing the busy tables to InnoDB was part of that change as well, and it all made a night and day difference. We finally outgrew the server about six months later and have moved up a couple notches since we first signed up.

    Just based on this experience, I would say that many hosts have a default configuration that is not exactly forum-friendly.
     
  15. Rudy

    Rudy Well-Known Member

    OK, I took a look at the server in question, and I noticed something interesting. Apache appears to be the web server, but there are a lot of entries for php-cgi, and the bulk of the CPU load is going into these php-cgi processes. Loads were routinely between 3.6 and 4.1 when I checked and, as I said, these php-cgi processes were eating up a good chunk of the CPU resources. (If the OP approves, I will post the screen shot I got from running "top".) There is also almost 2GB of unused memory, and while there is a lot of swap space allocated, none of the swap space is being used. So, there is an unused block of memory that could be utilized for further caching.

    Now, knowing Apache from my own two hosting accounts, we run PHP as an Apache module (mod-php), and I never see any php-cgi entries. If PHP is indeed running as CGI, I would probably suggest (if the host can accomodate) running PHP as an Apache module, and then installing APC or XCache to do some PHP opcode caching. Taking some of that load off the CPU would help MySQL process queries faster.

    Following that, I'd look at the MySQL configuration and make certain InnoDB is accounted for (many hosts assume their customers will mainly use MyISAM tables) and that the caches were set to an efficient size. Then, I'd install Sphinx to ease the load from MySQL.

    I will know more once we can put a phpinfo file on the web side and look more into the configuration.
     
  16. Rudy

    Rudy Well-Known Member

    Here is what "top" looks like:

    Code:
    top - 11:36:53 up 8 days, 21:41,  1 user,  load average: 3.73, 3.76, 3.41
    Tasks: 226 total,  5 running, 221 sleeping,  0 stopped,  0 zombie
    Cpu(s): 20.3%us,  1.6%sy,  0.0%ni, 77.7%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%s
    Mem:  8165076k total,  6087648k used,  2077428k free,  181672k buffers
    Swap:  8385920k total,        0k used,  8385920k free,  3861544k cached
    
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    1300 apache    16  0  161m  26m 6348 R 64.9  0.3  0:59.32 php-cgi
    1604 apache    16  0  163m  27m 6304 R 47.3  0.3  0:08.16 php-cgi
    1603 apache    16  0  157m  23m 5900 S 44.9  0.3  0:12.37 php-cgi
    1569 apache    16  0  157m  23m 5976 S 41.9  0.3  0:18.33 php-cgi
    1602 apache    16  0  156m  22m 5920 S 39.6  0.3  0:10.46 php-cgi
    1643 apache    16  0  152m  17m 5872 R 35.6  0.2  0:02.69 php-cgi
    1571 apache    16  0  158m  24m 6148 R 31.0  0.3  0:13.66 php-cgi
    5956 mysql    10  -5 1873m 923m 5500 S 23.0 11.6  1494:05 mysqld
    1570 apache    16  0  157m  23m 5956 S 14.0  0.3  0:20.01 php-cgi
    6077 squid    15  0  727m 681m 2304 S  5.3  8.6 479:25.46 cechd
    1572 apache    18  0  400m 6872 1580 S  2.0  0.1  0:00.67 httpd.worker
    1620 apache    19  0  399m 5852 1584 S  2.0  0.1  0:00.20 httpd.worker
    1601 360kpop  15  0 12764 1192  820 R  0.3  0.0  0:00.06 top
        1 root      15  0 10372  692  584 S  0.0  0.0  0:04.63 init
        2 root      RT  -5    0    0    0 S  0.0  0.0  0:00.08 migration/0
        3 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/0
        4 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/0
        5 root      RT  -5    0    0    0 S  0.0  0.0  0:27.89 migration/1
        6 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/1
        7 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/1
        8 root      RT  -5    0    0    0 S  0.0  0.0  0:31.14 migration/2
        9 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/2
      10 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/2
      11 root      RT  -5    0    0    0 S  0.0  0.0  0:29.44 migration/3
      12 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/3
      13 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/3
      14 root      RT  -5    0    0    0 S  0.0  0.0  0:05.44 migration/4
      15 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/4
      16 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/4
      17 root      RT  -5    0    0    0 S  0.0  0.0  0:16.87 migration/5
      18 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/5
      19 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/5
      20 root      RT  -5    0    0    0 S  0.0  0.0  1:00.29 migration/6
      21 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/6
      22 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/6
      23 root      RT  -5    0    0    0 S  0.0  0.0  0:23.96 migration/7
      24 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/7
      25 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/7
      26 root      RT  -5    0    0    0 S  0.0  0.0  0:07.30 migration/8
      27 root      34  19    0    0    0 S  0.0  0.0  0:01.28 ksoftirqd/8
      28 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/8
      29 root      RT  -5    0    0    0 S  0.0  0.0  0:28.54 migration/9
      30 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/9
      31 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/9
      32 root      RT  -5    0    0    0 S  0.0  0.0  0:23.91 migration/10
      33 root      34  19    0    0    0 S  0.0  0.0  0:00.00 ksoftirqd/10
      34 root      RT  -5    0    0    0 S  0.0  0.0  0:00.00 watchdog/10
      35 root      RT  -5    0    0    0 S  0.0  0.0  0:24.39 migration/11
      36 root      34  19    0    0    0 S  0.0  0.0  0:00.01 ksoftirqd/11
     

Share This Page