Clarify new CPU limits
Forum
  1. Forums
  2. CloudLinux and Control Panels
  3. CloudLinux and cPanel
  1. Jules Robinson
  2. Sunday, 20 July 2014
  3.  Subscribe via email
With the recent changes to CloudLinux and LVE manager, could you please clarify the new limits?

I notice the documentation says that \"speed\" is relative to number of cores, so \"100%\" means 1 full core, \"200%\" is 2 full cores and so on. Does this now make the \"nCPU\" parameter redundant if \"speed\" is set?

If \"speed\" is set to \"200%\" would \"nCPU\" be ignored?

Finally, can you also please clarify that changes to these settings no longer requires a reboot, or is this still the case?

Thanks in advance.
Rate this post:
  1. 23.07.2014 21:07:59
  2. # 21
Delta A Accepted Answer
Posts: 8
Joined: 07.05.2014
0
Votes
Undo
Bogdan

regarding the endless loop thing ... this has happened multiple times now on different servers (all with cloudlinux and all had 25% cpu limit and 1gb memory etc) 

Each time it was the Apache process that was eating all the ram even though there was an associated PHP process (simple php script with endless loop) and because apache is owned by root/nobody I guess it wasn't throttled. I just find it frustrating that a user can circumvent lve limits so easily (unintentionally). I opened a ticket about this some years ago when it happened the first time (it has happened again ..different users..different servers) and fr om memory Igor said LVE couldn't do anything about this because it's Apache and because it's probably due to mod_security or something.

I just find it emberassing when I have to tell a customer to check their php scripts for endless loops because I know how easily it can crash the server and still have no solution for it.

Would it not be possible to put LVE limits on Apache ? ie. atleast a memory lim it so that if it starts to consume more than X Gb of ram apache gets stopped and restarted automatically?
  1. 24.07.2014 09:07:30
  2. # 22
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
Votes
Undo
as we are working on a very big rework, that should add many cool featurs (like snapshoting of processes & queries when limits are hit, burstable limits and reseller limits). 
Great news ! Sounds very exciting :)
  1. 24.07.2014 10:07:25
  2. # 23
Delta A Accepted Answer
Posts: 8
Joined: 07.05.2014
0
Votes
Undo
Whilst I do appreciate your response and time you\'ve taken to write that Bogdan, my issue was to do with simple endless loops written by customers (by mistake) in PHP scripts, nothing to do with rewrites/redirects.

I guess I\'ll just have to find some other way to stop this from happening since LVE can\'t control apache. If anyone has any tips in which direction I should be looking I\'d very much appreciate it.
  1. 24.07.2014 10:07:43
  2. # 24
Igor Seletskiy Accepted Answer
Posts: 1194
Joined: 09.02.2010
0
Votes
Undo
Do you have that PHP script? Infinite loop in php is fully controled memory limits -- as long as you are using suPHP/mod_fcgid/mod_lsapi/or php via suexec.
If you use mod_php (with ITK, ruid2 or without) -- then yes, you cannot control memory for those PHP processes. Only CPU & IO. 
  1. 24.07.2014 10:07:11
  2. # 25
Delta A Accepted Answer
Posts: 8
Joined: 07.05.2014
0
Votes
Undo
Yeah I have the script somewhere .. but in bed now (1am here) so will get back to you soon with the script.

Basically what happened was from memory it was just a simple i for loop in that script .. I managed to take a screen shot of top before server crashed and it was showing apache as using 10gb ram + swap (out of 12 total ..just shortly before it crashed) and that script was one of the top processes too. But the ram was definately used up by apache for whatever reason.. I'll get back to you tommorow. Cheers

edit: all my servers run suPHP and have so for years now 
  1. 24.07.2014 23:07:39
  2. # 26
Delta A Accepted Answer
Posts: 8
Joined: 07.05.2014
0
Votes
Undo
OK found them ... 2 scripts from 2 different customers that managed to crash the servers via memory exhausting (endless loops in php). Can I email them to you directly or should I open a ticket at the helpdesk? Cheers D.
  1. 25.07.2014 00:07:51
  2. # 27
Igor Seletskiy Accepted Answer
Posts: 1194
Joined: 09.02.2010
0
Votes
Undo
Send it to me direct. [email protected]
yeBTW: 
when they crashed it -- was it apache process that became really big/ate up all the RAM? If yes, are you using mod_security with output filtering?
  1. 25.07.2014 00:07:31
  2. # 28
Delta A Accepted Answer
Posts: 8
Joined: 07.05.2014
0
Votes
Undo
Hey Igor, yes it was the Apache process that ate all the ram and swap. I am using Atomic\'s (paid) rulesets for cpanel which i *think* do include output filtering
  1. 25.07.2014 08:07:39
  2. # 29
Igor Seletskiy Accepted Answer
Posts: 1194
Joined: 09.02.2010
0
Votes
Undo
The issue is related to a bug in mod_security output filter.  The way it works -- it collects all the output (from script), and then checks it against a number of regexps to see if output doesn't leak any sensitive info, like credit card numbers.
It is all good, until you try to output 'infinite' amount of info (as in case of infinite loop that outputs something on each iteration). To store all that output, you would need infinite amount of RAM, and that is why your httpd processes balloon in size.
We had somewhere a script that kills big httpd processes, but this is still bad for performance (as big httpd process evicts caches). Right solution would be to disable (or fix) mod_security output filters.
  • Page :
  • 1
  • 2


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.

EU e-Privacy Directive

We use cookies to ensure you get the best experience using our website and services. Read more about it in our Privacy Policy. Please agree to the use of cookies to proceed. Alternatively, you may disable cookies in your browser at any time.

You have declined cookies. This decision can be reversed.

You have allowed cookies to be placed on your computer. This decision can be reversed.