My SQL DB is increasing at an alarming rate 10GB per day

deesignplay 2019-03-10 16:45:10 UTC #1

Keywords: WordPress - AWS - Technical issue - Other
Description:
Hi team,
Great responses so far and thanks for your help! I have an AWS Bitnami instance and i have had a problem of adding extra storage to the volume every now and then because i keep running out of space.
It seems like the MYSQL DB seems to chew up about close to 10GB per day even though the web level transacations does not reflect as much,nor does the amount of data in terms of pictures i am putting.
I have also enabled SSL - so its secure.. Is this potentially replication on the AWS storage that is causing this? or is the internal to Wordpress?
Could you please send me some tools to truncate or compress the DB in anyway so that i can optimize on space?

My DB keeps getting filled up - causing my AWS instance to go out of disk space, crashing my website

Same issue: Disk full, server no response, because mysql keep generating 1G log files

Can't start mysql after it went down mysteriosly

alejandror 2019-03-11 11:53:17 UTC #2

Hi @deesignplay,

According to these posts, you can analyze your database usage using the following queries:

Get size of each database:

SELECT table_schema "Data Base Name", sum( data_length + index_length ) / 1024 / 1024 "Data Base Size in MB" 
FROM information_schema.TABLES GROUP BY table_schema ;

Get size of each table in the bitnami_wordpress database:

SELECT 
    table_name AS `Table`, 
    round(((data_length + index_length) / 1024 / 1024), 2) `Table Size in MB` 
FROM information_schema.TABLES 
WHERE table_schema = "bitnami_wordpress";

In order to know the next steps we need to identify where is all that space being consumed. If it's due to not-reclaimed space, we could use these instructions from the official MySQL documentation to recover that space.

Also, if you are uploading multimedia files to the database, have you considered using a cloud file storage service, such as S3, as the backend? There are plugins that may ease the task to set this up and make it transparent for WordPress, also making your database smaller and likely more performant.

MySQL Data abnormally growing for unknown reason

MYSQL Data growing in size

Disk space in my instance

How to decrease mysql size?

deesignplay 2019-03-13 11:14:51 UTC #3

This is what i go when i ran the utility

_schema;

+--------------------+----------------------+
| bitnami_wordpress  | Data Base Size in MB |
+--------------------+----------------------+
| bitnami_wordpress  |      157769.79687500 |
| information_schema |           0.00000000 |
| mysql              |           2.40625000 |
| performance_schema |           0.00000000 |
| sys                |           0.01562500 |
+--------------------+----------------------+

Currently the storage is filling up at an alarming rate - i had to increase the size of the disk to 470GB

+--------------------------------+------------------+
| Table                          | Table Size in MB |
+--------------------------------+------------------+
| wp_booking                     |             0.02 |
| wp_bookingdates                |             0.02 |
| wp_cms2cms_connector_options   |             0.02 |
| wp_commentmeta                 |             0.05 |
| wp_comments                    |             0.16 |
| wp_hustle_modules              |             0.05 |
| wp_hustle_modules_meta         |             0.05 |
| wp_links                       |             0.03 |
| wp_options                     |        157747.52 |
| wp_pmxe_exports                |             0.02 |
| wp_pmxe_google_cats            |             0.39 |
| wp_pmxe_posts                  |             0.02 |
| wp_pmxe_templates              |             0.02 |
| wp_postmeta                    |             4.42 |
| wp_posts                       |            14.94 |
| wp_sgpb_subscribers            |             0.02 |
| wp_sgpb_subscription_error_log |             0.02 |
| wp_smush_dir_images            |             0.05 |
| wp_term_relationships          |             0.33 |
| wp_term_taxonomy               |             0.22 |
| wp_termmeta                    |             0.05 |
| wp_terms                       |             0.19 |
| wp_usermeta                    |             0.98 |
| wp_users                       |             0.19 |
| wp_yoast_seo_links             |             0.03 |
| wp_yoast_seo_meta              |             0.05 |
+--------------------------------+------------------+

Mysql creating a huge amount of bin files - That brings down website

deesignplay 2019-03-13 11:35:36 UTC #4

Thanks for your help! It ended up being the log.bin files that was filling up.
I manually ran a PURGE BINARY LOGS command, but need a way to automate the purging.

!/bin/bash

HRS=16
mysql -uroot -prootpass -e"PURGE BINARY LOGS BEFORE NOW() - INTERVAL ${HRS} HOUR"

Need to make this a part of cron

alejandror 2019-03-14 10:12:03 UTC #5

Hi @deesignplay,

Thanks for sharing this information. I'm glad you managed to find a way to mitigate the issue.

However, even though it could have temporarily worked, I'm not totally sure if this could be the definitive solution. As far as I know, these binary logs are used for synchronization between MySQL nodes. While it could be OK to remove them once the sync happens, there is a possibility that the files were still needed and data loss occurs. In fact, there is a built-in option to automatically purge these files, which is expire_logs_days, and is set by default to 30 days. You can find more information here.

I would like to look into this a little bit further.
The database table that seems to be taking most of the space is wp_options, which is shared by multiple plugins to store their information. Could you please share the list of plugins you have installed in WordPress? I would like to try reproducing the issue on my side.

Also, I suspect this could also be caused by the load balancers' health check mechanism, as would be continuously polling the WordPress site, and creating new sessions and/or transient data, which would be indeed recorded in the wp_options table of the database. You can check the number of transient fields with some DB queries like:

SELECT count(*) FROM wp_options WHERE option_name LIKE '%_transient_%';

The simplest approach to clean up these files would be by using a plugin like Transient Cleaner or WP-Optimize.

deesignplay 2019-03-23 06:29:00 UTC #6

Hi alejandror,

Thanks for your reply - Sorry for the late response on this as i was flying and i did not have good connectivity to check the status.

Currently i have 21 Active plugins - i optimized it. Some of the ones that i have is listed below :-

Booking Calendar,CMS2CMS Connector,Contact Form 7,Elementor,Featured Images in RSS for Mailchimp & Other Email,
Instagram Slider Widget,Mailchimp for WordPress,oAuth Twitter Feed for Developers,Penci Portfolio,Penci Recipe,
Penci Review,Penci Shortcodes,Penci Slider,Penci Soledad Demo Importer,Popup Builder,rewardStyle Widget,
Smush,Vafpress Post Formats UI,WordPress Users & WooCommerce Customers Import Export(BASIC,
WP Mail SMTP,Yoast SEO

Also, I suspect this could also be caused by the load balancers' health check mechanism, as would be continuously polling the WordPress site, and creating new sessions and/or transient data, which would be indeed recorded in the wpoptions table of the database. You can check the number of transient fields with some DB queries like:_

Copy
SELECT count(*) FROM wpoptions WHERE option_name LIKE '%transient%';_

I looked into this and i didnt see tthat the space was that large - but i may be reading the data wrong.
Database changed
mysql> SELECT count(*) FROM wp_options WHERE option_name LIKE '%transient%';
+----------+
| count(*) |
+----------+
| 17 |
+----------+
1 row in set (0.01 sec)

the only way i could get the space back again - was to again run the following command :-
PURGE BINARY LOGS BEFORE NOW() - INTERVAL 8 HOUR

I ended up gaining almost 250GB!! which seems odd - I agree with you that the load balancer is probably the problem since i added it, the rate of space consumption has been very high!
I am going to work to set the expire_logs_days, so that the log rotation is consistent.

deesignplay 2019-03-24 08:51:53 UTC #7

I think there is something else taking space,
I have been monitoring it over a couple of days - I can check the size by deleting the BINARY logs but still the overall size still increases. I will run into a bottleneck at some point -
is there a way to figure out what in MYSQL is taking up so much space, apart from the binary logs?

deesignplay 2019-03-24 08:53:41 UTC #8

Here is my current DB size
mysql> SELECT table_schema "database name",
-> sum( data_length + index_length ) / 1024 / 1024 "database size in MB",
-> sum( data_free )/ 1024 / 1024 "free space in MB"
-> FROM information_schema.TABLES
-> GROUP BY table_schema;

+--------------------+---------------------+------------------+
| database name      | database size in MB | free space in MB |
+--------------------+---------------------+------------------+
| bitnami_wordpress  |     291097.79687500 |      12.00000000 |
| information_schema |          0.00000000 |       0.00000000 |
| mysql              |          2.40625000 |     124.00000000 |
| performance_schema |          0.00000000 |       0.00000000 |
| sys                |          0.01562500 |       0.00000000 |
+--------------------+---------------------+------------------+

5 rows in set (0.55 sec)

alejandror 2019-03-25 11:09:17 UTC #9

Hi @deesignplay,

From previous message, I think the table that is taking most of the space is wp_options, so lets try to focus on it.
It would be really great if you could send us (privately) a dump of that table, although we understand this may not be able for you in case it contains sensitive data.

Following some tips I found in order to cleanup this table (here), could you please run the following queries in order to figure out what's are the biggest rows in this table?

SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10);

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 20;

deesignplay 2019-03-25 15:03:37 UTC #10

Thanks for your reply Sir!
Yep today again my / fs has grown to about 71% and no matter how much I truncate bin logs, it keeps increases on a daily rate at about 10%.
Focusing on what you have said in the thread,

1) For the first SQL query here is the output -

Database changed
mysql> SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
-> UNION
-> SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
-> UNION
-> (SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10);

+---------------------------+-------+
| name                      | value |
+---------------------------+-------+
| autoloaded data in KiB    |   158 |
| autoloaded data count     |   387 |
| wpseo_taxonomy_meta       | 67938 |
| rewrite_rules             | 20270 |
| theme_mods_soledad        | 13341 |
| wpseo_titles              |  7306 |
| wp_user_roles             |  5763 |
| widget_jr_insta_slider    |  3572 |
| cron                      |  3140 |
| widget_penci_about_widget |  2221 |
| fs_accounts               |  2004 |
| sidebars_widgets          |  1903 |
+---------------------------+-------+
12 rows in set (0.02 sec)

2) For the 2nd query the output is as follow :-

mysql> SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 20;

+----------------------------------+---------------------+
| option_name                      | option_value_length |
+----------------------------------+---------------------+
| wpseo_taxonomy_meta              |               67938 |
| rewrite_rules                    |               20270 |
| theme_mods_soledad               |               13341 |
| wpseo_titles                     |                7306 |
| wp_user_roles                    |                5763 |
| widget_jr_insta_slider           |                3572 |
| cron                             |                3140 |
| widget_penci_about_widget        |                2221 |
| fs_accounts                      |                2004 |
| sidebars_widgets                 |                1903 |
| widget_penci_social_widget       |                1750 |
| booking_form_visual              |                1705 |
| widget_penci_related_news_widget |                1489 |
| theme_mods_blog-times            |                1436 |
| active_plugins                   |                1073 |
| booking_email_new_admin          |                 880 |
| sgpb-banner-remote-get           |                 844 |
| booking_email_deleted            |                 773 |
| booking_email_deny               |                 773 |
| booking_email_trash              |                 773 |
+----------------------------------+---------------------+
20 rows in set (0.00 sec)

Until the system gets resolved , i am having to manually clean up logs almost every 4-5 hours so that i keep the system from filling the rootfs!
Thanks again for all your help!!

alejandror 2019-03-26 10:03:31 UTC #11

Hi @deesignplay,

Thanks for the information. This data seems to point to the problem caused by several rows of small-medium size, instead of very big rows. It would be interesting to see how this changes over time.
Could you please execute those queries again, now that some time has passed? Also, could you execute these other queries?:

SELECT count(*) FROM wp_options;

SELECT length(option_value) AS option_value_length, count(*) FROM wp_options GROUP BY option_value_length ORDER BY option_value_length;

Also, did you have a chance to check any of these plugins?

deesignplay 2019-03-28 03:15:09 UTC #12

Thanks @alejandror,

Here is what i got based on the what you asked for

Database changed

mysql> SELECT count(*) FROM wp_options;
+----------+
| count(*) |
+----------+
|      446 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT length(option_value) AS option_value_length, count(*) FROM wp_options GROUP BY option_value_length ORDER BY option_value_length;
+---------------------+----------+
| option_value_length | count(*) |
+---------------------+----------+
|                   0 |       29 |
|                   1 |       62 |
|                   2 |       37 |
|                   3 |       34 |
|                   4 |       10 |
|                   5 |       21 |
|                   6 |       14 |
|                   7 |        8 |
|                   8 |        6 |
|                   9 |        5 |
|                  10 |       23 |
|                  11 |        4 |
|                  12 |        3 |
|                  13 |        1 |
|                  14 |        1 |
|                  16 |        1 |
|                  17 |        1 |
|                  20 |        1 |
|                  21 |        3 |
|                  26 |        1 |
|                  27 |        3 |
|                  28 |        1 |
|                  30 |       46 |
|                  32 |        2 |
|                  36 |        3 |
|                  37 |        2 |
|                  40 |        3 |
|                  41 |        1 |
|                  45 |        1 |
|                  51 |        4 |
|                  66 |        3 |
|                  77 |        1 |
|                  78 |        1 |
|                  94 |        1 |
|                  97 |        1 |
|                  99 |        1 |
|                 101 |        1 |
|                 105 |        1 |
|                 125 |        1 |
|                 127 |        1 |
|                 136 |        1 |
|                 144 |        2 |
|                 146 |        1 |
|                 151 |        3 |
|                 153 |        1 |
|                 159 |        1 |
|                 160 |        1 |
|                 162 |        2 |
|                 166 |        7 |
|                 168 |        1 |
|                 169 |        1 |
|                 171 |        3 |
|                 173 |        4 |
|                 178 |        2 |
|                 188 |        1 |
|                 194 |        1 |
|                 195 |        1 |
|                 198 |        1 |
|                 201 |        1 |
|                 225 |        2 |
|                 229 |        1 |
|                 296 |        2 |
|                 300 |        1 |
|                 314 |        1 |
|                 319 |        1 |
|                 326 |        1 |
|                 329 |        1 |
|                 373 |        2 |
|                 402 |        1 |
|                 449 |        1 |
|                 467 |        1 |
|                 496 |        1 |
|                 512 |        1 |
|                 522 |        1 |
|                 545 |        1 |
|                 556 |        1 |
|                 578 |        1 |
|                 593 |        1 |
|                 594 |        1 |
|                 596 |        1 |
|                 597 |        1 |
|                 602 |        1 |
|                 623 |        1 |
|                 634 |        1 |
|                 647 |        1 |
|                 695 |        1 |
|                 704 |        1 |
|                 716 |        1 |
|                 736 |        1 |
|                 754 |        1 |
|                 773 |        3 |
|                 844 |        1 |
|                 880 |        1 |
|                 919 |        1 |
|                1112 |        2 |
|                1140 |        1 |
|                1231 |        1 |
|                1436 |        1 |
|                1458 |        1 |
|                1489 |        1 |
|                1513 |        1 |
|                1556 |        1 |
|                1567 |        1 |
|                1705 |        1 |
|                1750 |        1 |
|                1903 |        1 |
|                2004 |        1 |
|                2221 |        1 |
|                3313 |        1 |
|                3572 |        1 |
|                5763 |        1 |
|                7306 |        1 |
|               12281 |        1 |
|               13341 |        1 |
|               13478 |        1 |
|               14797 |        1 |
|               20270 |        1 |
|               39616 |        1 |
|               67938 |        1 |
|              326305 |        1 |
|             5768000 |        1 |
+---------------------+----------+
121 rows in set (0.01 sec)

We just installed wp-optimize - Can either of this clean up our db? Please let us know - looks like i have to increase my AWS EBS again to make do for the space.

Thanks again!

deesignplay 2019-03-28 05:25:30 UTC #13

HI @alejandror - Yep we ran wp-optmize.
It looks like it really cleaned up the system well!

Filesystem      Size  Used Avail Use% Mounted on
udev            488M     0  488M   0% /dev
tmpfs           100M  4.5M   95M   5% /run
/dev/xvda1      631G  9.7G  624G   2% /
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
/dev/loop0       92M   92M     0 100% /snap/core/6531
/dev/loop1       91M   91M     0 100% /snap/core/6350
/dev/loop2       13M   13M     0 100% /snap/amazon-ssm-agent/295
/dev/loop3       18M   18M     0 100% /snap/amazon-ssm-agent/1068
/dev/loop5       18M   18M     0 100% /snap/amazon-ssm-agent/930
/dev/loop4       91M   91M     0 100% /snap/core/6405
tmpfs           100M     0  100M   0% /run/user/1000

alejandror 2019-03-28 10:08:17 UTC #14

Hi @deesignplay,

Thanks a lot for the information.

I think there is something weird here. This data doesn't seem to match the table size seen in previous queries:

Could you please confirm you executed this query before running WP-Optimize plugin? Another option I could think of is data fragmentation in the database, due to not freeing the space after rows were deleted.

I'm glad you found a way of fixing this issue, but I'm also concerned it may come back in the future, so please don't hesitate to let us know in case that happens.

deesignplay 2019-03-28 15:57:20 UTC #15

Thanks @alejandror -

Is it possible because i have been cleaning up the logs? Potentially the reason why the data isnt matching.
But since last night - i did see about 86GB increase overnight in the db size which is still odd
But wp-optimize brought my space down by 95%!!

alejandror 2019-03-29 08:16:22 UTC #16

Hi @deesignplay,

I doubt that cleaning up the binary logs would affect the result of the queries we were using for troubleshooting.
It would be great if you could execute them before and after running wp-optimize so we can compare the results and try to identify the root cause of the problem

deesignplay 2019-03-29 17:42:26 UTC #17

You have been great @alejandror - let me do that in the next iteration and post the result here !

deesignplay 2019-03-29 20:57:08 UTC #18

Hi @alejandror - Not sure if this is related to wp-optimize or just AWS but i am getting a gateway timeout on the site since morning - I have opened a ticket with AWS - potentially my load balancer could be having an issue.
When i look at the services and restarted them - all of them look like they are running.

Wp_options size increases steadily without any "big" single entries

deesignplay 2019-03-29 21:41:27 UTC #19

HI @alejandror - Looks like i ran into a OOM killer scenario
When i did dmesg i saw this as the errors

[11276.735858] .php-fpm.bin[2113]: segfault at 7f5e26 ip 00000000007f5e26 sp 00007ffdb0250eb0 error 14 in .php-fpm.bin[980000+85a000]
[11282.685714] xpl_worker0 invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0
[11282.685718] xpl_worker0 cpuset=/ mems_allowed=0
[11282.685723] CPU: 0 PID: 1833 Comm: xpl_worker0 Not tainted 4.4.0-1077-aws #87-Ubuntu
[11282.685724] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
[11282.685726]  0000000000000286 2ed346a6df5b0685 ffff88003c3f79e8 ffffffff81406ce1
[11282.685728]  ffff88003c3f7ba0 ffff880037132940 ffff88003c3f7a58 ffffffff812143aa
[11282.685730]  0000000000000000 ffff88003bbdc300 ffff88003cdcee00 ffff88003c3f7a40
[11282.685732] Call Trace:
[11282.685739]  [<ffffffff81406ce1>] dump_stack+0x63/0x82
[11282.685743]  [<ffffffff812143aa>] dump_header+0x5a/0x1c3
[11282.685747]  [<ffffffff8139df34>] ? apparmor_capable+0xc4/0x1b0
[11282.685751]  [<ffffffff81198a6e>] oom_kill_process+0x1fe/0x3c0
[11282.685753]  [<ffffffff81198e99>] out_of_memory+0x219/0x460
[11282.685757]  [<ffffffff8119eeb3>] __alloc_pages_slowpath.constprop.88+0x943/0xaf0
[11282.685760]  [<ffffffff8119f2e8>] __alloc_pages_nodemask+0x288/0x2a0
[11282.685762]  [<ffffffff811ea97c>] alloc_pages_current+0x8c/0x110
[11282.685765]  [<ffffffff81194eeb>] __page_cache_alloc+0xab/0xc0
[11282.685767]  [<ffffffff811974e0>] filemap_fault+0x160/0x440
[11282.685771]  [<ffffffff812ad256>] ext4_filemap_fault+0x36/0x50
[11282.685773]  [<ffffffff811c4ba7>] __do_fault+0x77/0x110
[11282.685775]  [<ffffffff811c8b60>] handle_mm_fault+0x1270/0x1b80
[11282.685779]  [<ffffffff81830f81>] ? __schedule+0x301/0x810
[11282.685783]  [<ffffffff8106cd34>] __do_page_fault+0x1a4/0x410
[11282.685785]  [<ffffffff8106cfc2>] do_page_fault+0x22/0x30
[11282.685788]  [<ffffffff818389a8>] page_fault+0x28/0x30
[11282.685790] Mem-Info:
[11282.685794] active_anon:105851 inactive_anon:107029 isolated_anon:0
                active_file:108 inactive_file:161 isolated_file:0
                unevictable:913 dirty:0 writeback:0 unstable:0
                slab_reclaimable:5546 slab_unreclaimable:8299
                mapped:11314 shmem:12024 pagetables:2526 bounce:0
                free:12195 free_pcp:30 free_cma:0
[11282.685798] Node 0 DMA free:4548kB min:716kB low:892kB high:1072kB active_anon:4460kB inactive_anon:4740kB active_file:0kB inactive_file:84kB unevictable:180kB isolated(anon):0kB isolated(file):0kB present:15988kB managed:15900kB mlocked:180kB dirty:0kB writeback:0kB mapped:872kB shmem:904kB slab_reclaimable:212kB slab_unreclaimable:536kB kernel_stack:192kB pagetables:396kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:508 all_unreclaimable? yes
[11282.685803] lowmem_reserve[]: 0 959 959 959 959
[11282.685806] Node 0 DMA32 free:44232kB min:44336kB low:55420kB high:66504kB active_anon:418944kB inactive_anon:423376kB active_file:432kB inactive_file:560kB unevictable:3472kB isolated(anon):0kB isolated(file):0kB present:1032192kB managed:998528kB mlocked:3472kB dirty:0kB writeback:0kB mapped:44384kB shmem:47192kB slab_reclaimable:21972kB slab_unreclaimable:32660kB kernel_stack:7632kBpagetables:9708kB unstable:0kB bounce:0kB free_pcp:120kB local_pcp:120kB free_cma:0kB writeback_tmp:0kB pages_scanned:6004 all_unreclaimable? yes
[11282.685811] lowmem_reserve[]: 0 0 0 0 0
[11282.685813] Node 0 DMA: 5*4kB (UME) 4*8kB (UME) 5*16kB (UME) 8*32kB (ME) 5*64kB (UME) 4*128kB (UME) 1*256kB (U) 2*512kB (UE) 2*1024kB (UE) 0*2048kB 0*4096kB = 4548kB
[11282.685822] Node 0 DMA32: 1488*4kB (ME) 725*8kB (UME) 172*16kB (UME) 91*32kB (UME) 81*64kB (UME) 53*128kB (UME) 10*256kB (UME) 8*512kB (UME) 6*1024kB (UM) 1*2048kB (M) 0*4096kB = 44232kB
[11282.685832] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[11282.685833] 13093 total pagecache pages
[11282.685835] 192 pages in swap cache
[11282.685836] Swap cache stats: add 2396873, delete 2396681, find 900463/1632433
[11282.685837] Free swap  = 0kB
[11282.685838] Total swap = 649996kB
[11282.685839] 262045 pages RAM
[11282.685840] 0 pages HighMem/MovableOnly
[11282.685841] 8438 pages reserved
[11282.685842] 0 pages cma reserved
[11282.685843] 0 pages hwpoisoned
[11282.685844] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[11282.685848] [  437]     0   437    23693      154      15       3       50             0 lvmetad
[11282.685851] [  459]     0   459    10607      119      23       3      197         -1000 systemd-udevd
[11282.685853] [  532]     0   532     3051      380      11       3     1092             0 haveged
[11282.685855] [  540]     0   540     7088      403      18       3       56             0 systemd-journal
[11282.685857] [  754]   100   754    25081      348      19       3       48             0 systemd-timesyn
[11282.685859] [  962]     0   962     4031      346      12       3      204             0 dhclient
[11282.685861] [ 1144]     0  1144     1305       10       8       3       19             0 iscsid
[11282.685863] [ 1145]     0  1145     1430      878       8       3        0           -17 iscsid
[11282.685865] [ 1150]   104  1150    64098       76      28       3      179             0 rsyslogd
[11282.685867] [ 1158]     0  1158     1099      283       8       3       28             0 acpid
[11282.685869] [ 1160]     0  1160    68969      134      37       3      193             0 accounts-daemon
[11282.685871] [ 1167]   107  1167    10723      287      25       3      125          -900 dbus-daemon
[11282.685873] [ 1176]     0  1176     7252      376      20       3       63             0 cron
[11282.685875] [ 1179]     0  1179     6511      324      18       3       46             0 atd
[11282.685877] [ 1186]     0  1186    51669       13      26       5      656             0 amazon-ssm-agen
[11282.685879] [ 1204]     0  1204     5024      291      14       3       49             0 systemd-logind
[11282.685880] [ 1206]     0  1206    40226      243      15       4       72             0 lxcfs
[11282.685882] [ 1211]     0  1211    41337     1038      31       5     1640          -900 snapd
[11282.685885] [ 1218]     0  1218    16378      318      36       3      167         -1000 sshd
[11282.685887] [ 1271]     0  1271     3343      140      11       3       19             0 mdadm
[11282.685888] [ 1279]     0  1279    69272      397      38       3      165             0 polkitd
[11282.685890] [ 1481]     0  1481     1126      338       8       3       40             0 mysqld_safe
[11282.685892] [ 1800]  1001  1800   318172    80086     412       4    69962             0 mysqld.bin
[11282.685894] [ 1864]     0  1864    67313      350      53       4     1308             0 .php-fpm.bin
[11282.685896] [ 1865]     1  1865    92014    25452     124       4     3058             0 .php-fpm.bin
[11282.685898] [ 1872]     0  1872    50950      598     105       3      916             0 httpd.bin
[11282.685900] [ 1891]     1  1891   329919     3890     215       4    16774             0 httpd.bin
[11282.685902] [ 1892]     1  1892   330004     3972     212       4    14494             0 httpd.bin
[11282.685904] [ 2042]     1  2042    88648    23372     116       4     2308             0 .php-fpm.bin
[11282.685906] [ 2043]     1  2043   329854     4187     222       4    20696             0 httpd.bin
[11282.685908] [ 2113]     1  2113    89714    23879     120       4     3116             0 .php-fpm.bin
[11282.685910] [ 2115]     1  2115    93364    27364     126       4     2930             0 .php-fpm.bin
[11282.685912] [ 2117]     1  2117    91463    25857     122       4     2476             0 .php-fpm.bin
[11282.685914] [ 2154]     1  2154   329642     7510     221       4    15273             0 httpd.bin
[11282.685916] [ 2263]     0  2263     3245      210      11       5      137             0 gonit
[11282.685918] [ 2679]     0  2679     5732       65      16       3        0             0 apport
[11282.685919] Out of memory: Kill process 1800 (mysqld.bin) score 361 or sacrifice child
[11282.700516] Killed process 1800 (mysqld.bin) total-vm:1272688kB, anon-rss:320344kB, file-rss:0kB

Looks like there is no swap setup - should i set that up here? Let me know how i should proceed.

alejandror 2019-04-01 13:46:31 UTC #20

Hi @deesignplay,

Adding swap would likely have an impact on the server performance. Ideally, the correct way of addressing the issue would be to increase the instance type. You can find instructions on how to do it here.

Bitnami provides free all-in-one installers, virtual machines and cloud images for popular open source applications. Get them now!