Wordpress on Vultr 768



  • Is anyone running a Wordpress site on a 768 MB instance of Vultr?

    For a couple of days after initial setup, I was able to install MariaDB, Wordpress, etc, install a theme and some other plugins, and do some other site config. The site was working without issue. Now, almost all the time, the site just gives a "Error connecting to database" error. Upon further investigation, and watching the console, I figured out that the error is happening because the processes keep terminating (mysqld and httpd). Restarting the services fixes the problem for a couple of seconds, but then the server kills them again. When checking memory, the free available memory right after restarting the database server is extremely low. I'm assuming this is why the servers keeps killing the processes.

    Is this just a resource issue? Is a 768 MB server too small for a 1 site wordpress site?



  • @fuznutz04 said in Wordpress on Vultr 768:

    Is anyone running a Wordpress site on a 768 MB instance of Vultr?

    For a couple of days after initial setup, I was able to install MariaDB, Wordpress, etc, install a theme and some other plugins, and do some other site config. The site was working without issue. Now, almost all the time, the site just gives a "Error connecting to database" error. Upon further investigation, and watching the console, I figured out that the error is happening because the processes keep terminating (mysqld and httpd). Restarting the services fixes the problem for a couple of seconds, but then the server kills them again. When checking memory, the free available memory right after restarting the database server is extremely low. I'm assuming this is why the servers keeps killing the processes.

    Is this just a resource issue? Is a 768 MB server too small for a 1 site wordpress site?

    Depends on the traffic and how RAM accounting works at Vultr, but 768 MB is plenty if you don't face like 100.000 hits per hour. Most Wordpress sites only have like 128 MB, maybe 256 MB.



  • So you need to check out other possible causes for this



  • @thwr said in Wordpress on Vultr 768:

    So you need to check out other possible causes for this

    That's what I thought too. It's 1 site with currently no traffic at all. Any performance tuning I need to do on Apache, or mariaDB?



  • @fuznutz04 said in Wordpress on Vultr 768:

    @thwr said in Wordpress on Vultr 768:

    So you need to check out other possible causes for this

    That's what I thought too. It's 1 site with currently no traffic at all. Any performance tuning I need to do on Apache, or mariaDB?

    I don't know what exactly Vultr offers, is that a VM / container / jail? Just asking because you are able to check the running processes. RAM should be enough either way.

    I would first check the MariaDB/MySQL logs. The database shouldn't terminate itself without a reason.



  • @thwr said in Wordpress on Vultr 768:

    I don't know what exactly Vultr offers, is that a VM / container / jail?

    Full virtualization via KVM.



  • So a few things to get started:

    1. You need to configure your swap space, Vultr does not do this for you. So you are swapless and running with much less memory than you should be in that regard.
    2. 768MB is not very good for web serving. It can work, but you need to tune things, Apache especially as it will sprawl instantly.
    3. You need to look in the logs and see why the services said that they stopped.
    4. You need to look at the SAR reports to see what memory is doing. Move SAR up to every minute instead of every ten minutes for better info.


  • @fuznutz04 said in Wordpress on Vultr 768:

    Any performance tuning I need to do on Apache, or mariaDB?

    Yes, in HTTPD (Apache) you need to reduce the number of available idle threads. By default, Apache expects more excess memory and will use more than necessary.

    Check out the Apache tunings here, they might apply:

    https://mangolassi.it/topic/7011/reducing-memory-consumption-in-elastix-2



  • @thwr said in Wordpress on Vultr 768:

    Most Wordpress sites only have like 128 MB, maybe 256 MB.

    I doubt that most do, as it's effectively impossible for many years to even get VPS that small. Rackspace minimum is 512MB and DO/Vultr is like 768MB.



  • @scottalanmiller said in Wordpress on Vultr 768:

    So a few things to get started:

    1. You need to configure your swap space, Vultr does not do this for you. So you are swapless and running with much less memory than you should be in that regard.
    2. 768MB is not very good for web serving. It can work, but you need to tune things, Apache especially as it will sprawl instantly.
    3. You need to look in the logs and see why the services said that they stopped.
    4. You need to look at the SAR reports to see what memory is doing. Move SAR up to every minute instead of every ten minutes for better info.
    1. I setup swap previously.
    free -m
                  total        used        free      shared  buff/cache   available
    Mem:            740         255         247           1         237         369
    Swap:          1023         195         828
    
    1. I figured this was too low, but thought it might be manageable, especially just for testing and/or low usage.

    161107 11:04:55 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
    161107 11:05:52 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
    161107 11:05:52 [Note] /usr/libexec/mysqld (mysqld 5.5.47-MariaDB) starting as process 4727 ...
    161107 11:05:52 InnoDB: The InnoDB memory heap is disabled
    161107 11:05:52 InnoDB: Mutexes and rw_locks use GCC atomic builtins
    161107 11:05:52 InnoDB: Compressed tables use zlib 1.2.7
    161107 11:05:52 InnoDB: Using Linux native AIO
    161107 11:05:52 InnoDB: Initializing buffer pool, size = 32.0M
    161107 11:05:52 InnoDB: Completed initialization of buffer pool
    InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
    InnoDB: than specified in the .cnf file 0 8388608 bytes!
    InnoDB: Possible causes for this error:
     (a) Incorrect log file is used or log file size is changed
     (b) In case default size is used this log file is from 10.0
     (c) Log file is corrupted or there was not enough disk space
     In case (b) you need to set innodb_log_file_size = 48M
    161107 11:05:52 [ERROR] Plugin 'InnoDB' init function returned error.
    161107 11:05:52 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
    161107 11:05:52 [Note] Plugin 'FEEDBACK' is disabled.
    161107 11:05:52 [ERROR] Unknown/unsupported storage engine: InnoDB
    161107 11:05:52 [ERROR] Aborting
    
    161107 11:05:52 [Note] /usr/libexec/mysqld: Shutdown complete
    
    161107 11:05:52 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
    
    1. Running every 2 seconds, for 20 times, here is the output of sar -r when starting mariadb
    [[email protected] mariadb]# sar -r 2 20
    Linux 3.10.0-327.18.2.el7.x86_64 (web01) 	11/07/2016 	_x86_64_	(1 CPU)
    
    11:36:42 AM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
    11:36:44 AM    101484    657248     86.62       804     38136   1221556     67.59    263708    321164         4
    11:36:46 AM     60488    698244     92.03       140     55864   1595136     88.26    292536    333572        20
    11:36:48 AM     68760    689972     90.94      2140     81072   1627604     90.06    287536    332852        24
    11:36:50 AM     88352    670380     88.36       144     44408   1619720     89.62    307504    294980        96
    11:36:52 AM     52684    706048     93.06        80     20128   1649120     91.25    314700    325640         0
    11:36:54 AM     56232    702500     92.59        88      8924   1716380     94.97    318116    318592         4
    11:36:56 AM     59236    699496     92.19       112     14368   1801240     99.66    317428    315804         0
    11:36:58 AM     57804    700928     92.38        84     28560   1844356    102.05    317084    317404         0
    11:37:00 AM     56908    701824     92.50        84     15028   1924244    106.47    317200    317500         0
    11:37:02 AM     60052    698680     92.09        84      3912   2013736    111.42    314188    315084         0
    11:37:04 AM     57332    701400     92.44        84     24492   2090780    115.69    303708    324764         0
    11:37:06 AM     57672    701060     92.40       100     23932   2132812    118.01    311100    316180         0
    11:37:08 AM     49352    709380     93.50        84     28520   2311044    127.87    308568    320432         0
    11:37:10 AM     42416    716316     94.41        80     21308   2379376    131.65    318500    316644         0
    11:37:12 AM     59104    699628     92.21        84     17616   2515080    139.16    306896    309736         0
    11:37:14 AM     56912    701820     92.50        88     26100   2626604    145.33    307340    310396         0
    11:37:16 AM     75388    683344     90.06      1192     32580   2726348    150.85    282232    314996         0
    11:37:18 AM     52532    706200     93.08       324     16052   2226088    123.17    304344    313860         0
    11:37:20 AM     41032    717700     94.59      1296     18176   2335440    129.22    306512    318952         0
    11:37:22 AM     40488    718244     94.66       120     19404   2517688    139.31    305460    320248        20
    Average:        59711    699021     92.13       361     26929   2043718    113.08    305233    317940         8````


  • This might be a silly question but just to be 100% sure.... what is the disk space usage?

    df -h


  • Doesn't look like memory is the problem. You don't have a lot, but it's not being used.



  • @scottalanmiller said in Wordpress on Vultr 768:

    This might be a silly question but just to be 100% sure.... what is the disk space usage?

    df -h
    
    [[email protected] mariadb]# df -h
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/vda1        15G  3.1G   11G  22% /
    devtmpfs        362M     0  362M   0% /dev
    tmpfs           371M     0  371M   0% /dev/shm
    tmpfs           371M  9.6M  361M   3% /run
    tmpfs           371M     0  371M   0% /sys/fs/cgroup
    tmpfs            75M     0   75M   0% /run/user/1000
    


  • This is the bit that matters. InnoDB is freaking out.

    InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
    InnoDB: than specified in the .cnf file 0 8388608 bytes!
    InnoDB: Possible causes for this error:
     (a) Incorrect log file is used or log file size is changed
     (b) In case default size is used this log file is from 10.0
     (c) Log file is corrupted or there was not enough disk space
     In case (b) you need to set innodb_log_file_size = 48M
    161107 11:05:52 [ERROR] Plugin 'InnoDB' init function returned error.
    161107 11:05:52 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
    161107 11:05:52 [Note] Plugin 'FEEDBACK' is disabled.
    161107 11:05:52 [ERROR] Unknown/unsupported storage engine: InnoDB
    161107 11:05:52 [ERROR] Aborting
    

    And it is not memory that it is complaining about.



  • @fuznutz04 Okay, so plenty of disk space.



  • Which OS is this? What is the source of MariaDB?



  • @scottalanmiller said in Wordpress on Vultr 768:

    Which OS is this? What is the source of MariaDB?

    This is CentOS7. I set this server up a few months ago following this guide: https://jaredbusch.com/2014/08/11/how-to-install-wordpress-on-centos-7-minimal/

    As far as I remember, I don't remember deviating from it.



  • I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.



  • @fuznutz04 said in Wordpress on Vultr 768:

    @scottalanmiller said in Wordpress on Vultr 768:

    Which OS is this? What is the source of MariaDB?

    This is CentOS7. I set this server up a few months ago following this guide: https://jaredbusch.com/2014/08/11/how-to-install-wordpress-on-centos-7-minimal/

    As far as I remember, I don't remember deviating from it.

    I need to update that guide a bit one of these days.



  • @scottalanmiller said in Wordpress on Vultr 768:

    I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.

    Yes, it was runnning fine for at least a week, then I abandoned it for a few months, and recently revisited and started having these issues.



  • @fuznutz04 said in Wordpress on Vultr 768:

    @scottalanmiller said in Wordpress on Vultr 768:

    I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.

    Yes, it was runnning fine for at least a week, then I abandoned it for a few months, and recently revisited and started having these issues.

    Oh, you hurt it's feelings. That's a standard problem. Talk nice to it for a while.



  • @scottalanmiller said in Wordpress on Vultr 768:

    @fuznutz04 said in Wordpress on Vultr 768:

    @scottalanmiller said in Wordpress on Vultr 768:

    I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.

    Yes, it was runnning fine for at least a week, then I abandoned it for a few months, and recently revisited and started having these issues.

    Oh, you hurt it's feelings. That's a standard problem. Talk nice to it for a while.

    Could be. It's not a HUGE deal, as I can just blow it away and start over, but it would be nice to find out what's going on for if/when it happens again



  • @fuznutz04 said in Wordpress on Vultr 768:

    @scottalanmiller said in Wordpress on Vultr 768:

    @fuznutz04 said in Wordpress on Vultr 768:

    @scottalanmiller said in Wordpress on Vultr 768:

    I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.

    Yes, it was runnning fine for at least a week, then I abandoned it for a few months, and recently revisited and started having these issues.

    Oh, you hurt it's feelings. That's a standard problem. Talk nice to it for a while.

    Could be. It's not a HUGE deal, as I can just blow it away and start over, but it would be nice to find out what's going on for if/when it happens again

    Agreed. Since it is not mission critical, start with updates if those have not been run. 99% sure that that will not do anything, but you know, worth the test.



  • @scottalanmiller Yeah, that didn't fix it. I'll just start over. I recall discussion on here previously that the "one click" installs of Wordpress on Vultr are not recommended. I couldn't remember (or find the discussion) why this was the opinion...



  • Have you checked to see if these files exist and are correct size? Have you checked the .cnf file
    InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
    InnoDB: than specified in the .cnf file 0 8388608 bytes!

    Check your cnf file to see that it is correct. Rename/move ib_logfile0, ib_logfile1 (they'll get recreated when the service starts again)



  • @momurda said in Wordpress on Vultr 768:

    Have you checked to see if these files exist and are correct size? Have you checked the .cnf file
    InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
    InnoDB: than specified in the .cnf file 0 8388608 bytes!

    Check your cnf file to see that it is correct. Rename/move ib_logfile0, ib_logfile1 (they'll get recreated when the service starts again)

    I renamed and started the service again, and the files were re-created. The site is online for a few seconds then crashes again. I'm not seeing any configuration file other than /etc/my.cnf, and the file only has a few lines of code in it.

    [mysqld]
    datadir=/var/lib/mysql
    socket=/var/lib/mysql/mysql.sock
    # Disabling symbolic-links is recommended to prevent assorted security risks
    symbolic-links=0
    # Settings user and group are ignored when systemd is used.
    # If you need to run mysqld under a different user or group,
    # customize your systemd unit file for mariadb according to the
    # instructions in http://fedoraproject.org/wiki/Systemd
    
    [mysqld_safe]
    log-error=/var/log/mariadb/mariadb.log
    pid-file=/var/run/mariadb/mariadb.pid
    
    #
    # include all files from the config directory
    #
    !includedir /etc/my.cnf.d
    

    The files in /etc/my.cnf.d have almost nothing in them as well.



  • @fuznutz04 said in Wordpress on Vultr 768:

    @scottalanmiller Yeah, that didn't fix it. I'll just start over. I recall discussion on here previously that the "one click" installs of Wordpress on Vultr are not recommended. I couldn't remember (or find the discussion) why this was the opinion...

    That's correct, those are never recommended. Use the OS, not a third party system.



  • @fuznutz04
    I think there should be a bit more lines in that file.
    What size files are the recreated innodb files?
    What is the contents of /var/log/mariadb/mariadb.log



  • @momurda said in Wordpress on Vultr 768:

    @fuznutz04
    I think there should be a bit more lines in that file.
    What size files are the recreated innodb files?
    What is the contents of /var/log/mariadb/mariadb.log

    5242880 bytes is the size of the new files.

    Seems like I'm in a time warp, as it is warning me that my sequence numbers are in the future!

    161107 12:17:20  InnoDB: Waiting for the background threads to start
    161107 12:17:20  InnoDB: Error: page 348 log sequence number 133743653
    InnoDB: is in the future! Current system log sequence number 107618964.
    InnoDB: Your database may be corrupt or you may have copied the InnoDB
    InnoDB: tablespace but not the InnoDB log files. See
    InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
    InnoDB: for more information.
    161107 12:17:21 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
    

    So following the directions to force innodb into recovery mode, the DB starts, but then the logs say this:

    InnoDB: A new raw disk partition was initialized or
    InnoDB: innodb_force_recovery is on: we do not allow
    InnoDB: database modifications by the user. Shut down
    InnoDB: mysqld and edit my.cnf so that newraw is replaced
    InnoDB: with raw, and innodb_force_... is removed.
    InnoDB: A new raw disk partition was initialized or
    InnoDB: innodb_force_recovery is on: we do not allow
    InnoDB: database modifications by the user. Shut down
    InnoDB: mysqld and edit my.cnf so that newraw is replaced
    InnoDB: with raw, and innodb_force_... is removed.
    InnoDB: A new raw disk partition was initialized or
    InnoDB: innodb_force_recovery is on: we do not allow
    InnoDB: database modifications by the user. Shut down
    InnoDB: mysqld and edit my.cnf so that newraw is replaced
    InnoDB: with raw, and innodb_force_... is removed.
    161107 12:34:37 mysqld_safe Number of processes running now: 0
    161107 12:34:37 mysqld_safe mysqld restarted
    161107 12:34:40 [Note] /usr/libexec/mysqld (mysqld 5.5.50-MariaDB) starting as process 11049 ...
    161107 12:34:40 InnoDB: The InnoDB memory heap is disabled
    161107 12:34:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
    161107 12:34:40 InnoDB: Compressed tables use zlib 1.2.7
    161107 12:34:40 InnoDB: Using Linux native AIO
    161107 12:34:40 InnoDB: Initializing buffer pool, size = 128.0M
    InnoDB: mmap(137756672 bytes) failed; errno 12
    161107 12:34:40 InnoDB: Completed initialization of buffer pool
    161107 12:34:40 InnoDB: Fatal error: cannot allocate memory for the buffer pool
    161107 12:34:40 [ERROR] Plugin 'InnoDB' init function returned error.
    161107 12:34:40 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
    161107 12:34:40 [ERROR] mysqld: Out of memory (Needed 128917504 bytes)
    161107 12:34:40 [Note] Plugin 'FEEDBACK' is disabled.
    161107 12:34:40 [ERROR] Unknown/unsupported storage engine: InnoDB
    161107 12:34:40 [ERROR] Aborting
    


  • Just a bit of browsing I find this. You do actually seem to be out of memory, try adding

    performance_schema = off

    to the [mysqld] section of my.cnf


Log in to reply