Server issue needs to be fixed.
 

mysql is eating up resources.

[root@www public_html]# uptime
13:46:47 up 11 days, 1:53, 1 user, load average: 3.61, 4.31, 4.81

--------------------------------------------------------------------
contact me with quote only if you can fix it.
one time job.
Server is unmanaged.

thanks for your time.

What a fucking cheap bastard. :1orglaugh

there are companies out there, which dont provide "managed services" at any cost.
thanks

Well, in most cases like this it's not a real "server issue", but either mysql isn't configured to use the server's ressources correctly or mysql statements are not optimized.

Due to the unclear amount of work (depends a lot on the scripts used, if slow query logs are already in place, etc.) you won't get a "fixed price quote" from anyone with experience in this field. It would be possible to split the quote into 2 "jobs" - for once analyzing the server config / scripts - and after that one could estimate the hours to fix the issues.

If you want someone to look into it and aren't afraid of prices above indian level feel free to hit me up [email protected] - I've optimized a lot of large DBs in the past and I've also experience with various script languages accessing MySQL (which usually can be optimized as well) :thumbsup

contacting you now.

How about move your server over to us and I'll fix it for you. :-)

Skype: critical.net
AIM: NJesterIII

You're right, and people that cannot manage their own server are stupid if they haost there. Oh Hows your server going?? hahahaha:1orglaugh

:1orglaugh:1orglaugh:1orglaugh

Didn't get an email from you? Let me know if there was a problem contacting me.

What does your my.cnf look like? Please post it.

here it is.

on icq..

Try this:

[mysqld]
skip-locking
query_cache_limit=1M
query_cache_size=16M
query_cache_type=1
max_user_connections=100
max_connections=120
interactive_timeout=100
wait_timeout=10
connect_timeout=10
thread_cache_size=96
key_buffer=8M
join_buffer=1M
max_allowed_packet=8M
table_cache=1024
record_buffer=1M
sort_buffer_size=1024K
read_buffer_size=1024K
max_connect_errors=60
read_rnd_buffer_size=1024K
myisam_sort_buffer_size=16M
max_heap_table_size=256M
tmp_table_size=256M
old_passwords=1
local-infile=0
skip-innodb

[mysql.server]
user=mysql

[safe_mysqld]
open_files_limit=15000

[mysqldump]
quick
max_allowed_packet=8M
max_allowed_packet=8M

[mysql]
no-auto-rehash

[isamchk]
key_buffer=16M
sort_buffer=16M
read_buffer=8
write_buffer=8M

[myisamchk]
key_buffer=16M
sort_buffer=16M
read_buffer=8M
write_buffer=8M

[mysqlhotcopy]
interactive-timeout



Don't forget to restart mysql after saving the changes.


Anthony

Definitely looks like a script issue, since a properly written script should DEFINITELY not eat that many resources so quickly. I wouldn't be looking for a DBA, I'd look for a programmer to re-write your scripts. :2 cents:

:1orglaugh

thanks for reply.

innodb is a must as the script on server uses innodb dbs.

i have already contacted the coder and he says , its not the script issue.

thanks

what scripts do you run on the server? any of them get decent traffic? which script do you suspect is the problem?

Of course he says that. He made it. You should get another opinion from a more reputable coder. The stats from the errors prove a script issue...not a db issue.

I'm just trying to help. I'm not going to sit and argue about script versus db. I'll leave it at this. A script throttles the db, not the other way around. It's a script issue, period.

the server has mechbunny and inxy script, none of them get decent traffic.
but the inxy script uses innodb and has db of size 7 gbs. also few other db are 5-6 gbs. i guess thats the issue

sure thing i would do that.

thanks for your opinion, and no i am not arguing, i really appreciate your input.
ill again talk with coder and have him look at server.

thanks

Could be someone attempting a SQL injection, too.

Declare @q Varchar(8000) Select @q = 0x57414954464F522044454C4159202730303A30303A313527 Exec(@q) --

Will make the MySQL server sleep for 15 seconds. Check your logs for something like that.

Oh ok, I'm not using ICQ regularly, but I'm online now and replied to your message.

Most likely not the script itself, but queries it's launching. Mechbunny is used by a lot of bigger sites and konrad seems to be one of the good programmers - so I'd assume that's properly optimized. Can't speak for the other one as I've never heard of it before.

Anyway, the my.cnf needs to be properly configured too, but i find it kind of risky to make a suggestion for it without knowing details about the database(s) and server hardware. There's definitely no solution that fits every problem ...

If our script is on there, make sure you don't have the caching time in config.php set to some absurdly low level like 5 or 10 seconds.

it says ....

$video_cache_time = 3600; //video page cache time
$overall_cache_time = 1800; //cache time for all other pages

thanks, i guess those all were default values.