1

I have a centos 6 server running apache2, php and MySQL. The apache config has a few virtual sites as the server runs six websites, three of the six sites use MySQL and the other three do not.

Recently I have found that the sites using MySQL crash - report error "unable to connect to sql database.."

After looking in the logs, it looks like there are multiple instances of apache running which eat up all my memory - this causes the server to kill the MySQL process in order to stop the server from dieing, and moments later it will restore (on occasions I have to repair some tables)

In order to try and control the situation I have dropped my max_connections down to 100 - however this has not helped

Right now im not sure if I need more memory (1GB installed) or if I being DoS attacked. In all honesty we do expect high volumes of traffic to the server but how can I know if a single IP is continuously hitting the box?

I have pasted some output during "normal operation" below if it helps

free -m
             total       used       free     shared    buffers     cached
Mem:           992        771        221          0         15         87
-/+ buffers/cache:        668        323
Swap:          976         39        937

ps aux | grep apache
apache   17148  0.1  3.4 430836 35036 ?        S    06:34   0:10 /usr/sbin/httpd
apache   17150  0.1  3.3 430592 34560 ?        S    06:34   0:12 /usr/sbin/httpd
apache   17157  0.1  3.3 333192 33896 ?        S    06:34   0:13 /usr/sbin/httpd
apache   17164  0.1  3.3 333712 33984 ?        S    06:34   0:09 /usr/sbin/httpd
apache   17167  0.1  3.4 430576 34584 ?        S    06:34   0:12 /usr/sbin/httpd
apache   17168  0.1  3.3 430064 34312 ?        S    06:34   0:11 /usr/sbin/httpd
apache   17176  0.1  3.3 430564 34560 ?        S    06:34   0:11 /usr/sbin/httpd
apache   17184  0.1  3.4 432124 35500 ?        S    06:34   0:08 /usr/sbin/httpd
apache   17186  0.1  3.3 430088 34384 ?        S    06:34   0:14 /usr/sbin/httpd
apache   17188  0.1  3.3 333464 34028 ?        S    06:34   0:13 /usr/sbin/httpd
apache   17190  0.1  3.4 430548 34616 ?        S    06:34   0:08 /usr/sbin/httpd
apache   17193  0.1  3.3 333372 33548 ?        S    06:34   0:12 /usr/sbin/httpd
apache   17195  0.1  3.4 333716 34672 ?        S    06:34   0:11 /usr/sbin/httpd
apache   17225  0.1  3.3 430044 33584 ?        S    06:35   0:10 /usr/sbin/httpd
apache   17239  0.1  3.4 430568 34796 ?        S    06:35   0:11 /usr/sbin/httpd
apache   17241  0.1  3.3 430480 34284 ?        S    06:35   0:11 /usr/sbin/httpd
apache   17290  0.1  3.4 430948 34824 ?        S    06:35   0:10 /usr/sbin/httpd
apache   21095  0.1  3.1 331300 32344 ?        S    08:15   0:01 /usr/sbin/httpd
apache   30858  0.1  3.2 430148 33304 ?        S    Aug04   0:49 /usr/sbin/httpd
apache   31996  0.1  3.2 430168 33480 ?        S    Aug04   0:48 /usr/sbin/httpd
2
  • Impossible to answer for us. Check your (access) logfiles, check your graphs for slow increase or spikes in traffic/hits/MySQL connections, etc.
    – faker
    Aug 5, 2013 at 8:51
  • Grep through your kernel logs for oom or Killed. I suspect you are running out of memory and MySQL is being killed. It would also be worth running mysqltuner.pl to evaluate MySQL's memory requirements. Adding a resource graphing tool like Cacti, Munin, Zabbix, Observium, etc. would be a good idea too.
    – Ladadadada
    Aug 5, 2013 at 9:10

2 Answers 2

1

Looks like you need more RAM. You also can reduce max amount of HTTPd processes or max memory param for PHP.

4
  • RAM is cheap. Buy more RAM. Aug 5, 2013 at 9:26
  • Cheap is always relative depending on the project size income and where they are hosting it. Highschooler on aws having to pay an extra 50$ a month may be a fortune amount of money
    – WojonsTech
    Aug 5, 2013 at 9:37
  • @WojonsTech If you're on a budget for hosting and use AWS, you're doing it wrong.
    – Nathan C
    Aug 5, 2013 at 12:13
  • yeah totally i agree but aws was an example some people like doing things wrong for what ever reason.
    – WojonsTech
    Aug 5, 2013 at 20:06
0

I agree with @PauRudnitskiy but Just a few things you should look into before just throwing more memory at the problem.

Like Paul stated take a look at your apache config and see the max number of children and connections your allowed to have. If the max children is also the number of processes that are running then it could be your having an issue.

Also check what your system load is by using the following command

uptime

It will look something like this

02:22:35 up 4:07, 4 users, load average: 0.10, 0.08, 0.06

if the numbers after "load average" look large then that show that you are under attack. Simply divde the largest number there by the number of cpu cores you have, if the result is greater then 1 then it means your cpu is full.

Lastly just to add what i am showing you is really to see if your under a traffic spike or under extra load. You will need to look at your apache logs to to try and see if your under some kind of attack normally this is seen by the same ip address making lots of requests to the page, and other things normal users would not do.

5
  • I wouldn't say it means the OP's server is under attack, it could be a valid large traffic spike. Aug 5, 2013 at 9:27
  • yeah that is totally true ddos is really someone trying to take you down with legitimate traffic
    – WojonsTech
    Aug 5, 2013 at 9:30
  • There could be many reasons for a high CPU usage on a server, and a (D)DoS attack is one of them.
    – Frederik
    Aug 5, 2013 at 9:32
  • If you're being DDoS'd you'd know it...mostly because 1) you can't access your server anyway, and 2) your host decides to null route you.
    – Nathan C
    Aug 5, 2013 at 12:14
  • in times where i have servers with 5000 load average i have still been able to login an run a few commands they take a really long time to return though. the person is also on a 1gb machine so it would not take much to dos them
    – WojonsTech
    Aug 5, 2013 at 20:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .