• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

MySQL freezing everyday

I worte before that I have another server with Plesk within.
this server is dedicated hosting for 1 web site only.
this web site is not using mysql.

just wanted to bring your attention to something:

User: XPARTYWSERV\Plesk Administrator
Running task: "C:\Program Files\SWsoft\Plesk\admin\bin\statistics.exe"
Started: Thu Oct 27 05:00:00 2005
The task output is attached to the e-mail Ended successfully: Thu Oct 27 13:09:59 2005


just wanted to know , why does it takes more then 6 hours to finish the statistics process ??? !!!
 
Could it be running in Low Priotiry > So other processes have higher priority ?

(Yust a guess)
 
Had the same freezing issue with mysql. Was sesrvice pack 1 for windows 2003 that caused the problems. Removed it and everything is stable again.
 
Originally posted by sebastian
Had the same freezing issue with mysql. Was sesrvice pack 1 for windows 2003 that caused the problems. Removed it and everything is stable again.

Yeah... removing a Service Pack that has 1010 (!) fixes for your OS is a real smart thing to do...
 
Yeah... removing a Service Pack that has 1010 (!) fixes for your OS is a real smart thing to do...

And not having a stable database is better? Our database would freeze between 4 to 9 times a day. You still have security updates for bugs in sp0, so you should be pretty safe.
 
Okay
So I'm not the only one with this problem eh?

I'm still looking for a solution to this buzzle!

The server specs are:
Pentium 4 2.8GHz
1GB RAM
2x80GB

Around 1 month ago I contacted SWsoft about this issue, and they told me this:

Usually there are no problems with statistics in PSA Version: 7.5.4. We can suggest you edit the MySQL parameters to improve MySQL performance.

Also our records indicate that you have purchased through one of our resellers.

As such, they are your first point of contact for support and general inquiry. If they can't / won't support you we would like to know this. Additionally, we would like to offer you the following options if you wish to receive support from SWsoft.

And my reseller didn't know what the hell is going on (at the time of the post,) so I just disabled the statistics.exe task from the task manager, and I was until now running the task manually to keep an eye on the MySQL process and make a move if needed!

I installed "MySQL Administrator", and by monitoring the server I noticed that the number of connections increase steady before the MySQL server hangs!

Also I noticed that you can't restart the MySQL service unless you kill the process...

And this is a copy from my.ini

Code:
[MySQLD]
port=3306
basedir=C:\\Program Files\\SWsoft\\Plesk\\Databases\\MySQL
datadir=C:\\Program Files\\SWsoft\\Plesk\\Databases\\MySQL\\Data
tmpdir=e:\\temp\\
default-character-set=latin1
default-storage-engine=INNODB
query_cache_limit=1M
query_cache_size=32M
query_cache_type=1
table_cache=1024
tmp_table_size=7M
thread_cache=128
myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
myisam_sort_buffer_size=2M
key_buffer_size=16M
read_buffer_size=2M
read_rnd_buffer_size=256K
sort_buffer_size=2M
join_buffer=1M
innodb_additional_mem_pool_size=2M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=1M
innodb_buffer_pool_size=16M
innodb_log_file_size=10M
innodb_thread_concurrency=8
max_connections=300
key_buffer=128M
max_allowed_packet=17824768
sort_buffer=2M
net_buffer_length=8K
old_passwords=1

innodb_table_locks=1
innodb_lock_wait_timeout=30 

connect_timeout=10
interactive_timeout=60
wait_timeout=60

[client]
port=3306

[mysqldump]
quick
max_allowed_packet=16M

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

[mysqlhotcopy]
interactive-timeout

I'll continue on my experiments and see if siren method would fix this EVIL problem....
 
Saaaaay
It worked man!

my.ini
Code:
[MySQLD]
port=3306
basedir=C:\\Program Files\\SWsoft\\Plesk\\Databases\\MySQL
datadir=C:\\Program Files\\SWsoft\\Plesk\\Databases\\MySQL\\Data
tmpdir=e:\\temp\\
default-character-set=latin1
default-storage-engine=INNODB
query_cache_limit=1M
query_cache_size=32M
query_cache_type=1
table_cache=1024
tmp_table_size=7M
thread_cache=128
myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
myisam_sort_buffer_size=2M
key_buffer_size=16M
read_buffer_size=2M
read_rnd_buffer_size=256K
sort_buffer_size=2M
join_buffer=1M
innodb_additional_mem_pool_size=24M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=10M
innodb_buffer_pool_size=64M
innodb_log_file_size=10M
innodb_thread_concurrency=8
max_connections=300
key_buffer=48M
max_allowed_packet=17824768
sort_buffer=2M
net_buffer_length=8K
old_passwords=1

innodb_table_locks=1
innodb_lock_wait_timeout=30 

connect_timeout=10
interactive_timeout=60
wait_timeout=60

[client]
port=3306

[mysqldump]
quick
max_allowed_packet=16M

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

[mysqlhotcopy]
interactive-timeout

Looks like it is in fact a problem on the innodblog files...

I'll continue looking and I'll post again if it gets broken again!
 
OK

The MySQL server got broken again after 9 hours...
That's a total of 9 runs without errors, but it got broken again!

I'll contact my reseller again and see if they got a solution for this problem
 
Removing SP1 is not a resolution, it's not even a realistic work around. Many of the updates (including security updates) are not included in hotfixes.

I highly doubt Perl has anything to do with the problem in and of itself.

kawanda: I noticed you only updated the innodb, some of your other settings are low also. Such as query cache size, etc....

I would recommend optimizing your my.ini fully and then giving it a shot.

Also running mysqlcheck -A -r -o

Depending on domains you may also want to optimize the plesk my.ini \plesk\mysql\data\ as it willl increase the performance of plesk.

A server we upgraded to 7.5.5 with 780 domains and growing has been running everything flawlessly.

System Uptime: 10 day(s) 13:25

We've restarted services a few times, but nothing in the last 96 hours.
 
It seems that after running the repair and optimize MYSQL that statistics will run.

Now i first run this and after that I run manually statistics. For the last 2 days it seems the solution.

Maybe an application doesn't work good with mysql.
 
For the 4th day it looks like the solution i found works.
I made a batchfile like this:

cd\
cd Program Files\SWsoft\Plesk\MySQL\bin
mysqlcheck -uadmin -p -A -r -o
cd\Program Files\SWsoft\Plesk\admin\bin
statistics

Now MySQL doesn't crash. Tables are repaired and optimised before the statistics are made.

Maybe this solution helps everyone with this problem. I yust run a cronjob calling this batchfile
 
Hello

tI have been able to run successfully the statistics.exe
but it was only 2 days
so lets give more time

I have also configured to run mysqlcheck 1 hour before the statistics is running

lets hope that we found a final sollution for this issue

I will update you in the end of this week
 
Hello,
so we are in the end of the week.

Just want to update all that the issue with statistics.exe still exist

for people who have forget the issue , I will update them:

statistics.exe result in alot's of mysql connection and then the mysql stop working
 
untill now my problem is solved when i furst run the mysqlcheck and than statistics.

The problem that remains is when i start backup in the night, pleskservices willnot restart.
I now run backup without disabling suspending controlpanel and domain operations. This works for me.
 
hi guys,

firstly it seems not about sp1 because, we have got many machines with specs
3.2 dual xeon 64 bit extreme cpus and
2 gb ddr2 rams. and many of them has got sp1 many of them has not.

but other servers are getting mysql freeze problem always which are sp0

but I foun't this if mysql usage not so much mysql is not freezing but if server is using too much mysql then mysql crashing.

it seems about innodb storage unit log. because some times we need to delete some domains from psa database. then when I logging phpmyadmin it seems innodb logs for examle free 4000 kb then you can able to delete or to do what you want. but if it seems less then 1000 kb pma is not doing what you want. for example you are trying to delete a data record but status bar is not going to the end, and pma is not doing process.
 
Until now problem stays with statistics.exe.
Most weird was last friday. When i started it after a while I noticed a huge amount of fields that where corrupted (from 1 website i saw approx 105.000 records corrupted (allthough site has no problems) (and more sites with currupted records)

Before running statistics i allwas let check, repair and optimize the tables, but it looks like that didn't work.

Since than there is no way to get statistics.exe running. All hope was in the new plesk Update to 7.5.5 But as it looks right now i better forget statistics.exe as the problem still is there after the update.

I further noticed that when users create or edit a mysql database that the system sometimes crashes.
 
Dear All,


1-Should we enable InnoDB engine by running <path>MySQL\bin\mysqld-max-nt instead of mysqld-nt.exe?


2- don't you think this issue has been appearing since Plesk is based on two MySQL rather one in version 7.0.3 ? (MySQL for plesk and MySQL for clients)

3- As we all know the issue is remaining unresolved, don't you agree, SW-SOFT should assign one person to monitor the issue we are experiencing and to give everyone updates and make sugesstions so we all test and give them feedbacks?

We really need this to be resolved ASAP,

Regards
 
still freezing :/

Okaytation

So my reseller gave me a link to the MySQL manual.
And I spent 1 week restudying that, and discovered some "weird" effects, now I'm starting to think...

"When you try to dump the MySQL tables with Innodb, you'll get stalled if you have errors on the Index structure or if you don't use special lock measures."

I think they should improve the way statistics.exe measures the size of the databases
Since the current method would stall the database whenever some one tries to visit the site with the database in question, or whenever there is an error on the indexing!

Knowing this, I'm disabling statistics.exe until we get a "practical solution" to this problem.
Since me and my clients are growing really tired from it too...

1-Should we enable InnoDB engine by running <path>MySQL\bin\mysqld-max-nt instead of mysqld-nt.exe?

PLESK MySQL doesn't have "mysqld-max-nt"

2- don't you think this issue has been appearing since Plesk is based on two MySQL rather one in version 7.0.3 ? (MySQL for plesk and MySQL for clients)

Now if we think about it, this is a true fact
Maybe the other theory that statistics.exe is not measuring the size of the database rather than searching the database!

But why a search operation would stall the database?
This is the question!

3- As we all know the issue is remaining unresolved, don't you agree, SW-SOFT should assign one person to monitor the issue we are experiencing and to give everyone updates and make sugesstions so we all test and give them feedbacks?

Very true, in fact 90% of billing applications rely on the statistics.exe results to calculate the space and bandwidth usage!

No statistics = clients to overuse the resources with you too late to discover it! :eek:

This is not funny man!!!
 
Yeah problem keeps on. Even when users try to create a table mysql crashes. It's getting me crazy as i always have to restart the mysqld-nt service (client one)

I wished it could be solved. But the reseller where i bought Plesk doesn't know what to do.

As it seems Plesk for Windows support is not that easy.

:mad:
 
We now are some weeks further and after the update to plesk 7.5.5 the problem with mysql consists.

Mysql sometimes MYSQL runs a few days stable, but it keeps on crashing unexpectingly.

Did anyone find a solution ?
 
Back
Top