Arie Skliarouk's questions

The server with i7 CPU (Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz) under linux kernel 3.0.0 (3.0.0-10-server) generally works properly, but when it is put under heavy load - it overheats (as shown by "sensors" program) and locks up (with bunch "CPU temperature too high" messages on the console).

I have cpufreqd daemon running, which dutifully throttles CPU speed from 3060000 Hz to 1596000 Hz. Yet this is not enough to reduce CPU temperature under heavy load.

I suspect that there is fan/heatsink/thermal paste problem somewhere, which I am going to check on first opportunity.

Is there anything else I can do to slow down the CPU to prevent it from overheating?

We are doing offsite mysql replication over long distance and limited bandwidth - latency of about 200ms and about 70KB/s (max).

The replication works sporadically, transferring several tens of kilobytes and then reconnecting.

I have traced the problem to bad tcp/ip behavior of the mysqld daemon on the client - when a single tcp/ip packet is lost, the whole ACK/retransmit sequence can not recover the connection and at some point server issues FIN.

It is notable that scp from the same server works properly (even with packets lost that happens occasionally).

Mysql client from the client machine to the server also works properly and occasional packet loss does not break the connection.

Both server and client have the same version of mysql server:

mysql> SHOW VARIABLES LIKE '%version%';
+-------------------------+---------------------+
| Variable_name           | Value               |
+-------------------------+---------------------+
| protocol_version        | 10                  | 
| version                 | 5.0.67-0ubuntu6-log | 
| version_comment         | (Ubuntu)            | 
| version_compile_machine | x86_64              | 
| version_compile_os      | debian-linux-gnu    | 
+-------------------------+---------------------+
5rows in set (0.21 sec)

Might this caused by packets loss that happens when TCP/IP attempts to raise TCP/IP window beyond what is allowed by the connection?

Glusterfs, while being a nice distributed filesystem, provides almost no way to monitor it's integrity. Servers can come and go, bricks might get stale or fail and I afraid to know about that when it is probably too late.

Recently we had an strange failure when everything appeared working, but one brick fell out from the volume (found by pure coincidence).

Is there a simple and reliable way (cron script?) that will let me know about health status of my GlusterFS 3.2 volume?