Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
The MySQL server is restarting frequently. 75 times in less than 24 hours. And finally its ending without restarting!
Please check the details log here: mysqld.log
140113 10:18:22 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140113 10:18:31 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140113 10:18:31 InnoDB: Initializing buffer pool, size = 8.0M
140113 10:18:31 InnoDB: Completed initialization of buffer pool
140113 10:18:31 InnoDB: Started; log sequence number 16 1064411530
140113 10:18:32 [Note] Event Scheduler: Loaded 0 events
140113 10:18:32 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.61' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
140113 18:45:09 mysqld_safe Number of processes running now: 0
140113 18:45:10 mysqld_safe mysqld restarted
140113 18:45:10 InnoDB: Initializing buffer pool, size = 8.0M
140113 18:45:10 InnoDB: Completed initialization of buffer pool
140113 18:45:10 InnoDB: Started; log sequence number 16 1064411530
140113 18:45:11 [Note] Event Scheduler: Loaded 0 events
140113 18:45:11 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.61' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
......
140114 9:50:12 InnoDB: Initializing buffer pool, size = 8.0M
140114 9:50:12 InnoDB: Completed initialization of buffer pool
140114 9:50:12 InnoDB: Started; log sequence number 16 1064411530
140114 9:50:13 [Note] Event Scheduler: Loaded 0 events
140114 9:50:13 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.61' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
140114 09:55:07 mysqld_safe Number of processes running now: 0
140114 09:55:07 mysqld_safe mysqld restarted
140114 9:55:08 InnoDB: Initializing buffer pool, size = 8.0M
140114 9:55:08 InnoDB: Completed initialization of buffer pool
140114 09:55:08 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
In the meantime its killing 62 processes due to out of memory. Please check the detail log: messages
Jan 14 09:41:53 centos63 kernel: Out of memory: Kill process 16795 (mysqld) score 20 or sacrifice child
Jan 14 09:41:53 centos63 kernel: Killed process 16795, UID 27, (mysqld) total-vm:574508kB, anon-rss:20488kB, file-rss:164kB
I am running a cronjob in each 5 minutes which is affecting some tables with about 200000, 50000, 25000 data in three tables.
SELECT over 1,257 members then over 9,844 member_boards and then INSERT/UPDATE over 168,624 member_cards using the below pseudocode:
<?php
$qry = _("SELECT _members");
while($member = mysql_fetch_assoc($res))
{//1,257
$qry = _("SELECT _member_boards");
while($db_board = mysql_fetch_assoc($board_res))
{//9,844
$s_lists = curl_download("https://api.com/boards/lists");
foreach ($lists as $list) {//9,844
if(!strcmp('SOMETHING', $list->name)){//Matching with API and DB
$curl = "https://api.com/lists/cards";
foreach ($cards as $card) {//168,624
$qry = _("SELECT _member_cards");
if($card_row = mysql_fetch_assoc($card_res)){
$qry = _("UPDATE _member_cards");
}
else{
echo $qry = _("INSERT _member_cards");
}
}
}
}
}
$qry = _("UPDATE _member_cards");
}
?>
So what can be the reason and how can I solve this issue?
RAM 512 MB until now.
CentOS
Can scaling RAM up to 1 GB solve the issue?
Your MySQL server is getting killed because it uses too much memory; you can either add more RAM to the server or try lowering MySQL's memory usage by changing some values in its configuration file; however that may affect performance.
Take a look at this question and this one for guides about tweaking MySQL's configuration - it's not an easy task and it's based on trial and error, you should try different values until you get a good balance between performance and memory usage.
Related
I have a problem. When I split my MariaDB from main server to another server (my database server is running MariaDB docker from latest tag) I got an error:
Got an error writing communication packets
i have 2 server the one is a webserver (no db) the other is a ubuntu 20.04 with 4gig ram and 4 core(2gh per core)
The port is open and my PING is less than 1ms.
I tried with a basic WP site DB and the connection is OK, there was no problem, but my database is about 1GB and I guess this made this problem.
I also try to connect over private network (192.168.100.25) instead of public IP, but the problem is same.
Here is my MariaDB log
Aborted connection 3 to db: 'wpdb' user: 'root' host: 'myip' (Got an error reading communication packets)
Aborted connection 5 to db: 'wpdb' user: 'root' host: 'myip' (Got an error writing communication packets)
I also edited MariaDB config:
increased max_allowed_packet to 1GB
increased net_buffer_length to 1000000
but nothing changes!
here is mariadb variable :
https://pastebin.ubuntu.com/p/yHFRh7CnVC/
SHOW GLOBAL STATUS:
https://pastebin.pl/view/b3db2b91
show process list:
8,root,31.56.66.249:60612,,Query,0,starting,SHOW FULL PROCESSLIST,0
ulimit on server root:
ubuntu#rangoabzar:~$ ulimit -a
ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 15608
max locked memory (kbytes, -l) 65536
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 15608
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
ulimit in docker container:
root#63aa95764534:/# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 15608
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1048576
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
iostat
htop
I got this same error by doing a query that returned multiple rows, then processing those rows using rows.Next() (in Golang), and exiting early because of an unrelated error without calling rows.Close(). The confusing part was that it worked the first few times, but eventually failed, indicating some resource (connections?) was being used up.
I was able to take advantage of Golang's defer statement, and just do
defer rows.Close()
before ever calling rows.Next(), but calling rows.Close() before every early exit from the rows.Next() loop works as well.
I upgraded mySQL from 5.5. to 5.7. I am not being able to make MAMP running MYSQL. Error log gives that:
160617 14:45:13 mysqld_safe Starting mysqld daemon with databases from /Applications/MAMP/db/mysql
2016-06-17T09:45:13.908521Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2016-06-17T09:45:13.976451Z 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.
2016-06-17T09:45:13.976701Z 0 [Note] /Applications/MAMP/Library/bin/mysqld (mysqld 5.7.9) starting as process 28255 ...
2016-06-17T09:45:14.111330Z 0 [Warning] Setting lower_case_table_names=2 because file system for /Applications/MAMP/db/mysql/ is case insensitive
2016-06-17T09:45:14.136797Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-06-17T09:45:14.136828Z 0 [Note] InnoDB: Uses event mutexes
2016-06-17T09:45:14.136838Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2016-06-17T09:45:14.136849Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-06-17T09:45:14.137452Z 0 [Note] InnoDB: Number of pools: 1
2016-06-17T09:45:14.145153Z 0 [Note] InnoDB: Not using CPU crc32 instructions
2016-06-17T09:45:14.230174Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2016-06-17T09:45:14.299060Z 0 [Note] InnoDB: Completed initialization of buffer pool
2016-06-17T09:45:14.395299Z 0 [ERROR] InnoDB: ./ib_logfile0 can't be opened in read-write mode.
2016-06-17T09:45:14.395336Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2016-06-17T09:45:14.707209Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2016-06-17T09:45:14.707274Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2016-06-17T09:45:14.707335Z 0 [ERROR] Failed to initialize plugins.
2016-06-17T09:45:14.707361Z 0 [ERROR] Aborting
2016-06-17T09:45:14.707400Z 0 [Note] Binlog end
2016-06-17T09:45:14.707585Z 0 [Note] Shutting down plugin 'CSV'
2016-06-17T09:45:14.719175Z 0 [Note] /Applications/MAMP/Library/bin/mysqld: Shutdown complete
160617 14:45:14 mysqld_safe mysqld from pid file /Applications/MAMP/tmp/mysql/mysql.pid ended
Fix
Open up a terminal and chown MAMP's mysql database folder :
sudo chown -R `whoami`:admin /Applications/MAMP/db/mysql
Explanation
I just ran into the same error, the hint is here :
[ERROR] InnoDB: ./ib_logfile0 can't be opened in read-write mode.
It means that the user running mysqld isn't allowed to read-write. But _mysql is the owner of this file :
-rw-r----- 1 _mysql admin 50331648 10 avr 22:35 ib_logfile0
I ran ps -axj | grep mysql right after launching the server, and saw I was the owner of mysqld, instead of being owned by _mysql.
It's a breaking change, I think we should have been warned in the release note.
Few hours ago, Mysql shuts down on my production server. I've tried to restart it with 'service mysqld restart' as usual (I'm on a centos), but:
MySQL Daemon failed to start.
In my log file, I have :
151125 10:53:10 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151125 10:53:10 InnoDB: Initializing buffer pool, size = 8.0M
151125 10:53:10 InnoDB: Completed initialization of buffer pool
151125 10:53:10 InnoDB: Started; log sequence number 0 6283559
01:53:10 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8384512
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338336 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x29) [0x8509b9]
/usr/libexec/mysqld(handle_fatal_signal+0x483) [0x6a3ef3]
/lib64/libpthread.so.0() [0x3e59e0f790]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
151125 10:53:10 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
I am losing potential clients every second, so I will appreciate your help, thank you
EDIT
Problem solved ! My partition was full :
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 15G 15G 0M 100% /
I've deleted some useless backups/logs files and restart mysql.
Thank you
I think this is an issue in code somewhere, but the code's so simple I'm not sure what it could be.
I've verified wait_timeout is high enough and have gone through everything here: http://dev.mysql.com/doc/refman/5.1/en/gone-away.html without any success.
This happens reproducibly on the second query executed in one script run so I'm sure it's a coding error.
I created a really simple wrapper around the PDO class to have a singleton database handle:
<?php
class PDOWrapper
{
protected static $instance;
protected $dbh;
function __construct()
{
if ( is_null(static::$instance) )
{
static::$instance = $this;
$this->connect_to_db();
}
}
static function instance()
{
if ( is_null(static::$instance) )
{
new static;
}
return static::$instance;
}
private function connect_to_db()
{
$db_info = array(
0 => array(
'hostname' => "Host",
'username' => "User",
'password' => "Pass",
'db' => "DB",
)
);
//Try to connect to the database
try
{
$dbh = new PDO('mysql:host=' . $db_info[0]['hostname'] . ';dbname=' . $db_info[0]['db'], $db_info[0]['username'], $db_info[0]['password'], array( PDO::ATTR_PERSISTENT => true, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_EMULATE_PREPARES => true ));
}
catch (PDOException $e)
{
log_message("Error connecting to DB!: " . $e->getMessage(), LOG_LEVEL_CRITICAL );
return false;
}
$this->dbh = $dbh;
}
public static function get_dbh()
{
if ( is_null(static::$instance) )
{
new static;
}
return static::$instance->dbh;
}
}
I then use the wrapper like so:
function somefunc(){
$dbh = PDOWrapper::get_dbh();
$future_sth = $dbh->prepare("SELECT * FROM some_table");
$future_sth->execute();
$ret = $future_sth->fetchAll(PDO::FETCH_ASSOC);
print_r($ret);
$future_sth->closeCursor();
return $ret;
}
I call this function repeatedly as part of an event loop. The first time it calls it, the print_r runs fine and it prints out the rows I expect to see.
After the function has been executed once, however, I get the following:
Warning: Error while sending QUERY packet. PID=92871
Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away'
I don't know why it'd have "gone away". My my.cnf looks ok. Wait timeout is massive and this happens immediately as soon as I run the second query anyway. Any ideas?
It doesn't look like anything is obviously wrong in the MySQL error log:
120925 12:48:46 mysqld_safe Starting mysqld daemon with databases from /usr/local/var/mysql
120925 12:48:46 [Warning] The syntax '--log' is deprecated and will be removed in a future release. Please use '--general-log'/'--general-log-file' instead.
120925 12:48:46 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
120925 12:48:46 InnoDB: The InnoDB memory heap is disabled
120925 12:48:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120925 12:48:46 InnoDB: Compressed tables use zlib 1.2.5
120925 12:48:46 InnoDB: Initializing buffer pool, size = 128.0M
120925 12:48:46 InnoDB: Completed initialization of buffer pool
120925 12:48:46 InnoDB: highest supported file format is Barracuda.
120925 12:48:46 InnoDB: Waiting for the background threads to start
120925 12:48:47 InnoDB: 1.1.8 started; log sequence number 2273680401
120925 12:48:47 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
120925 12:48:47 [Note] - '0.0.0.0' resolves to '0.0.0.0';
120925 12:48:47 [Note] Server socket created on IP: '0.0.0.0'.
120925 12:48:47 [Note] Event Scheduler: Loaded 0 events
120925 12:48:47 [Note] /usr/local/Cellar/mysql/5.5.25a/bin/mysqld: ready for connections.
Version: '5.5.25a-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution
I figured it out.
I was working on a multi-process daemon using pcntl_fork. The parent process was responsible for running a loop to query the database and fork children to perform additional work depending on what data it saw.
The children didn't need a DB connection, however they were still given one because pcntl_fork was used. I was just using exit() to kill the child processes when they were done with their work, which caused the 'friendly' PHP cleanup to close the active MySQL connection it perceived the child to have.
Control would go back to the parent, who would find their DB connection was suddenly no longer valid when they tried to find more data in the database to send off to children.
The fix, for me, was to use posix_kill(getmypid(), 9); to kill the children rather than exit();.
trying to get my first little PHP script to connect to a local mySql database and am having some trouble. I used a cookie cutter script from the net to get going and am having some issues. In order to debug so far all I've done is place echo statements before and after the line where I connect to the database and noticed that there is a problem with the connection statement.
Here is the code i'm using, taken verbatim from W3Schools:
<?php
$con = mysql_connect("localhost","peter","abc123");
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_select_db("my_db", $con);
$result = mysql_query("SELECT * FROM Persons");
while($row = mysql_fetch_array($result))
{
echo $row['FirstName'] . " " . $row['LastName'];
echo "<br />";
}
mysql_close($con);
?>
Naturally I changed the passwords and all that and verified that I can connect to the database from the mysql command line tool.
Any tips would be greatly appreciated.
Here is the log located at: /var/log/mysql/error.log
Version: '5.1.54-1ubuntu4' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
110727 1:38:22 [Note] /usr/sbin/mysqld: Normal shutdown
110727 1:38:22 [Note] Event Scheduler: Purging the queue. 0 events
110727 1:38:23 InnoDB: Starting shutdown...
110727 1:38:25 InnoDB: Shutdown completed; log sequence number 0 15895194
110727 1:38:25 [Note] /usr/sbin/mysqld: Shutdown complete
110727 14:08:56 [Note] Plugin 'FEDERATED' is disabled.
110727 14:08:56 InnoDB: Initializing buffer pool, size = 8.0M
110727 14:08:56 InnoDB: Completed initialization of buffer pool
110727 14:08:57 InnoDB: Started; log sequence number 0 15895194
110727 14:08:58 [Note] Event Scheduler: Loaded 0 events
110727 14:08:58 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.54-1ubuntu4' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
SO I learn't how to get some meaningful debug info from PHP thanks to #nix, add the following lines to the top of the php file:
ini_set('display_errors', 1);
ini_set('log_errors', 1);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');
Well. try restarting mysql daemon:
sudo service mysqld restart
try connecting to mysql from command line using
-h localhost
and
-h 127.0.0.1
Also - check for exact error you're getting in:
/var/log/mysql.err
or
/var/log/mysql/mysql.log
P.S. your code works for me.
UPDATE:
So - in the end as it turns out - mysqli was disabled in PHP. Problem solved.:)
So it turns out that the php5-mysql library was not installed.
sudo apt-get install php5-mysql
that's it!
Thanks to #nix for taking care of this one.