too much entry processes

[hustreamload]

Hello!

Our forum is running on a shared server (hosting24.com), which has a limit on parallel running processes, CPU etc. In the last 3 weeks 3-4 times appeared a new problem: without any unexpected bigger number of visitors the entry processes reach the 17 limit, and cannot reach the site with error message "resource limit is reached". Earlier it happened also several times, but after a couple of minutes we could login succesful. But in the last weeks when the site reached the entry process limit, it rem,ained so, and we could kill them only with the of providers support.

I've controlled all the test on SMF and in phpmyadmin, everything seesms to be ok, no bugs. Ok, I refereshed the SMF (v2.06), switced off some applications, but after 1-2 days the story began  again. I've uploaded Bot buster, Stop forum spam and Forum firewall (ok, the last banned me, and till today couldnt really switch on), but these didnt solve the problem.

As I have a long conversation already with the provider , I can here copy a couple of detailed info:

1. The details of the processes that were causing the issue (from 3-4 days ago, of course I didnt ask them to write me every time)
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
672123 strea334 20 0 596m 199m 9048 S 0.0 0.8 0:12.63 /usr/local/apache/bin/httpd: 89.135.197.32 [streamloadforum.com] GET /index.php?board=150.0 HTTP/1.0
672971 strea334 20 0 616m 218m 8208 S 0.0 0.9 0:11.47 /usr/local/apache/bin/httpd: 89.135.197.32 [streamloadforum.com] GET /index.php?board=150.0 HTTP/1.0
673924 strea334 20 0 575m 174m 6696 S 0.0 0.7 0:02.50 /usr/local/apache/bin/httpd: 89.135.197.32 [streamloadforum.com] GET /index.php?board=150.0 HTTP/1.0
676092 strea334 20 0 598m 199m 8896 S 0.0 0.8 0:12.24 /usr/local/apache/bin/httpd: 89.135.197.32 [streamloadforum.com] GET /index.php?board=139.0 HTTP/1.0
676532 strea334 20 0 591m 192m 6420 S 0.0 0.8 0:01.89 /usr/local/apache/bin/httpd: 89.135.197.32 [streamloadforum.com] GET /index.php?board=150.0 HTTP/1.0
676546 strea334 20 0 591m 194m 8080 S 0.0 0.8 0:07.04 /usr/local/apache/bin/httpd: 89.135.197.32 [streamloadforum.com] GET /index.php?topic=77370.msg291156;boardseen
676570 strea334 20 0 601m 204m 8560 S 0.0 0.9 0:05.79 /usr/local/apache/bin/httpd: 89.135.197.32 [streamloadforum.com] GET /index.php?board=150.0 HTTP/1.0
677359 strea334 20 0 595m 195m 6288 S 0.0 0.8 0:01.24 /usr/local/apache/bin/httpd: 89.135.197.32 [streamloadforum.com] GET /index.php?board=150.0 HTTP/1.0
701090 strea334 20 0 586m 187m 8992 S 0.0 0.8 0:16.20 /usr/local/apache/bin/httpd: 195.38.126.142 [streamloadforum.com] GET /index.php?board=160.20 HTTP/1.0
701786 strea334 20 0 597m 198m 8984 S 0.0 0.8 0:16.64 /usr/local/apache/bin/httpd: 195.38.126.142 [streamloadforum.com] GET /index.php?board=160.20 HTTP/1.0
704420 strea334 20 0 603m 206m 8540 S 0.0 0.9 0:08.54 /usr/local/apache/bin/httpd: 195.38.126.142 [streamloadforum.com] GET /index.php?board=330.0 HTTP/1.0
704634 strea334 20 0 577m 178m 6608 S 0.0 0.7 0:02.80 /usr/local/apache/bin/httpd: 195.38.126.142 [streamloadforum.com] GET /index.php?board=160.0 HTTP/1.0
738876 strea334 20 0 594m 196m 7740 S 0.0 0.8 0:04.32 /usr/local/apache/bin/httpd: 188.6.40.241 [streamloadforum.com] GET /index.php HTTP/1.0
740985 strea334 20 0 611m 214m 8688 S 0.0 0.9 0:07.57 /usr/local/apache/bin/httpd: 188.6.40.241 [streamloadforum.com] POST /index.php?PHPSESSID=4c747e1baea06ecacff5
740994 strea334 20 0 596m 198m 6952 S 0.0 0.8 0:02.96 /usr/local/apache/bin/httpd: 188.6.40.241 [streamloadforum.com] POST /index.php?PHPSESSID=4c747e1baea06ecacff5
741771 strea334 20 0 567m 167m 6108 S 0.0 0.7 0:01.18 /usr/local/apache/bin/httpd: 188.6.40.241 [streamloadforum.com] GET /index.php?PHPSESSID=4c747e1baea06ecacff5d
741890 strea334 20 0 466m 160m 4088 S 0.0 0.7 0:00.04 /usr/local/apache/bin/httpd: 188.6.40.241 [streamloadforum.com] GET /index.php HTTP/1.0

2. I've copied from phpmyadmin the details of the status of DB, only the alert values:
- Aborted clientsDocumentation 43.5 k - The number of connections that were aborted because the client died without closing the connection properly.
- Aborted connectsDocumentation 1.1 M - The number of failed attempts to connect to the MySQL server.
- Created tmp disk tablesDocumentation 6.7 M The number of temporary tables on disk created automatically by the server while executing statements. If Created_tmp_disk_tables is big, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.
- Handler read rndDocumentation 3.3 G - The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.
- Handler read rnd nextDocumentation 424.7 G - The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
- Innodb buffer pool pages dirtyDocumentation 27 - The number of pages currently dirty.
- Innodb buffer pool readsDocumentation 58.7 M - The number of logical reads that InnoDB could not satisfy from buffer pool and had to do a single-page read.
- Innodb log waitsDocumentation 60 - The number of waits we had because log buffer was too small and we had to wait for it to be flushed before continuing.
- Innodb row lock time avgDocumentation 74 - The average time to acquire a row lock, in milliseconds.
- Innodb row lock time maxDocumentation 2.2 k - The maximum time to acquire a row lock, in milliseconds.
- Innodb row lock waitsDocumentation 940 - The number of times a row lock had to be waited for.
- Opened tablesDocumentation 1.1 M - The number of tables that have been opened. If opened tables is big, your table cache value is probably too small.
- Qcache free blocksDocumentation 19.5 k - The number of free memory blocks in query cache. High numbers can indicate fragmentation issues, which may be solved by issuing a FLUSH QUERY CACHE statement.
- Qcache lowmem prunesDocumentation 78.6 M - The number of queries that have been removed from the cache to free up memory for caching new queries. This information can help you tune the query cache size. The query cache uses a least recently used (LRU) strategy to decide which queries to remove from the cache.
- Select full joinDocumentation 987.7 k - The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
- Select range checkDocumentation 369 k - The number of joins without keys that check for key usage after each row. (If this is not 0, you should carefully check the indexes of your tables.)
- Slow queriesDocumentation 1 k - The number of queries that have taken more than long_query_time seconds.Documentation
- Sort merge passesDocumentation 21 k - The number of merge passes the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable.
- Table locks waitedDocumentation 8.4 M - The number of times that a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.

Can you recommend any change of settings in DB or any mod in SMF, which can solve this error?

Thnx in advance
HuStreamload

[Arantor]

Well, how big is your forum and what mods are installed?

[hustreamload]

Hello!

The DB is 220 MB, only the smf_messages table is almost 100 MB (we exsist since 2003). We tried to cut that, but cannot do already lower without loosing info. We don't use uploaded images or bigger files for downloading.

The modifications:
Aeva ~ Auto-Embed Video & Audio    7.2    
6 Custom buttons / tabs with Sub Menus
Embed BBCode    1.8
Stop Forum Spam    1.0    
Captcha on Reminder
nCode Image Resizer    1.3.1
Board Viewers Mod    1.2.1.1b
Minimum Characters for Search    1.2    
SimplePortal    2.3.5
Forum Firewall    1.1.6
Enhanced Dropdown    1.3
Language Drop Down    1.5.3
Bot Buster    1.1
Users Online Today    2.0.3

[hustreamload]

I've set 2 things, and today the server traffic seems to be normal:
1. Use database driven sessions - on (This option makes use of the database for session storage - it is best for load balanced servers, but helps with all timeout issues and can make the forum faster.)
2. Caching Level - Leves 1 switced on (the server has Memcached installed)
I don't know really, does it help, or not, have you any idea?

[Arantor]

Neither should actually affect your problem. Your principle problem is actually the fact that it looks like you've outgrown your host's limitations.

[margarett]

Your principle problem is actually the fact that it looks like you've outgrown your host's limitations.

This, and the amount of times the word "Unlimited" is used in your host's page is the "buzzer" to change to a non-overselling host...

[hustreamload]

Thnx, with the settings above seems to be Ok. If the probleme returns, I will be looking for another host. Can you recommend any, where this limits are much higher or didnt exist as well?