View Single Post
  #6 (permalink)  
Old 03-01-2007, 04:10 AM
CJ.deb CJ.deb is offline
Active Member
 
Posts: 30
Default

Quote:
Originally Posted by brian View Post
How much memory does your server have? Your buffer settings in /opt/zimbra/conf/my.cnf might be set too high, during the initial install. Check the output in /opt/zimbra/db/data/.err for malloc errors, on startup. We had another report of this same error and that was the cause.
Hi Brain

8GB memory -> can be set to high ;-)
Hope for your advise.

cheers
Christian


* cat /proc/meminfo
MemTotal: 8308584 kB
MemFree: 5386764 kB
Buffers: 100784 kB
Cached: 1158656 kB
SwapCached: 0 kB
Active: 2032176 kB
Inactive: 756248 kB
HighTotal: 7470840 kB
HighFree: 4771520 kB
LowTotal: 837744 kB
LowFree: 615244 kB
SwapTotal: 2031608 kB
SwapFree: 2031608 kB
Dirty: 608 kB
Writeback: 0 kB
Mapped: 1518228 kB
Slab: 109328 kB
CommitLimit: 6185900 kB
Committed_AS: 6350096 kB
PageTables: 7888 kB
VmallocTotal: 106488 kB
VmallocUsed: 3000 kB
VmallocChunk: 102984 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB

* /opt/zimbra/conf/my.cnf

[mysqld]

basedir = /opt/zimbra/mysql
datadir = /opt/zimbra/db/data
socket = /opt/zimbra/db/mysql.sock
pid-file = /opt/zimbra/db/mysql.pid
bind-address = localhost
port = 7306
user = zmbra

skip-external-locking

log-slow-queries = /opt/zimbra/log/myslow.log
long-query-time = 1
log-long-format
log-queries-not-using-indexes
log-bin

thread_cache = 71
max_connections = 71

# We do a lot of writes, query cache turns out to be not useful.
query_cache_type = 0

sort_buffer_size = 1048576
read_buffer_size = 1048576

# Increase the size of the table cache, since each mailbox has its
# own set of tables
table_cache = 500

innodb_buffer_pool_size = 2552400690
innodb_log_file_size = 104857600
innodb_log_buffer_size = 8388608
innodb_file_per_table

[mysqld_safe]

err-log = /opt/zimbra/log/mysqld.log

__________________________________________________ ________

* cat /opt/zimbra/db/data/.err

Sorry couldn't give the upgrade a new try at the moment.

Just attached the "gibberish" out of the error file. Will give it a clean try asap.

------------------------------------------------------
InnoDB: Error in opening ./ibdata1
070224 16:52:45 InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means 'Resource temporarily unavailable'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.0/...ror-codes.html
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
070224 16:52:45 [Note] /opt/zimbra/mysql/libexec/mysqld: ready for connections.
Version: '5.0.33-log' socket: '/opt/zimbra/db/mysql.sock' port: 7306 Source distribution
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
070224 16:52:46 InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
070224 16:52:46 InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means 'Resource temporarily unavailable'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.0/...ror-codes.html
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
070224 16:52:46 [ERROR] Can't start server: Bind on TCP/IP port: Address already in use
070224 16:52:46 [ERROR] Do you already have another mysqld server running on port: 7306 ?
070224 16:52:46 [ERROR] Aborting

070224 16:52:46 [Note] /opt/zimbra/mysql/libexec/mysqld: Shutdown complete

InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
070224 16:52:46 InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
070224 16:52:46 InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means 'Resource temporarily unavailable'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.0/...ror-codes.html
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
070224 16:52:46 [ERROR] Can't start server: Bind on TCP/IP port: Address already in use
070224 16:52:46 [ERROR] Do you already have another mysqld server running on port: 7306 ?
070224 16:52:46 [ERROR] Aborting

070224 16:52:46 [Note] /opt/zimbra/mysql/libexec/mysqld: Shutdown complete

070224 16:52:46 mysqld ended

070224 16:52:46 mysqld ended

070224 16:53:05 InnoDB: We now intentionally generate a seg fault so that
InnoDB: on Linux we get a stack trace.
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=0
read_buffer_size=1044480
max_used_connections=0
max_connections=71
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 145123 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
Cannot determine thread, fp=0xbfe5988c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x816df93
0x8366ac9
0x8366b9a
0x8363e05
0x8320e05
0x832551a
0x8292755
0x822ab43
0x8220a32
0x816e30e
0x8171f21
0x1d8de3
0x80e63f1
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/us...ack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
070224 16:53:05 mysqld ended

070224 16:54:53 mysqld started
070224 16:54:53 [Warning] One can only use the --user switch if running as root

070224 16:54:53 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=zmail-bin' to avoid this problem.
070224 16:54:54 InnoDB: Error: cannot allocate 161631436 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 2740576092 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
070224 16:55:54 InnoDB: We now intentionally generate a seg fault so that
InnoDB: on Linux we get a stack trace.
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=0
read_buffer_size=1044480
max_used_connections=0
max_connections=71
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 145123 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
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...
Cannot determine thread, fp=0xbfecb90c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x816df93
0x8366ac9
0x8366b9a
0x8363e05
0x8320e05
0x832551a
0x8292755
0x822ab43
0x8220a32
0x816e30e
0x8171f21
0x1d8de3
0x80e63f1
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/us...ack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
070224 16:55:54 mysqld ended

070224 17:00:26 mysqld started
070224 17:00:26 [Warning] One can only use the --user switch if running as root

070224 17:00:26 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=zmail-bin' to avoid this problem.
070224 17:00:28 InnoDB: Started; log sequence number 0 242054503
070224 17:00:28 [ERROR] Can't start server: Bind on TCP/IP port: Address already in use
070224 17:00:28 [ERROR] Do you already have another mysqld server running on port: 7306 ?
070224 17:00:28 [ERROR] Aborting

070224 17:00:28 InnoDB: Starting shutdown...
070224 17:00:30 InnoDB: Shutdown completed; log sequence number 0 242054503
070224 17:00:30 [Note] /opt/zimbra/mysql/libexec/mysqld: Shutdown complete

070224 17:00:30 mysqld ended

070224 17:44:20 mysqld started
070224 17:44:20 [Warning] One can only use the --user switch if running as root

070224 17:44:20 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=zmail-bin' to avoid this problem.
070224 17:44:21 InnoDB: Started; log sequence number 0 242054503
070224 17:44:21 [ERROR] Can't start server: Bind on TCP/IP port: Address already in use
070224 17:44:21 [ERROR] Do you already have another mysqld server running on port: 7306 ?
070224 17:44:21 [ERROR] Aborting

070224 17:44:21 InnoDB: Starting shutdown...
070224 17:44:24 InnoDB: Shutdown completed; log sequence number 0 242054503
070224 17:44:24 [Note] /opt/zimbra/mysql/libexec/mysqld: Shutdown complete

070224 17:44:24 mysqld ended

070224 17:47:55 [Note] /opt/zimbra/mysql/libexec/mysqld: Normal shutdown

070224 17:47:55 [Note] /opt/zimbra/mysql/libexec/mysqld: Shutdown complete

070224 17:47:55 mysqld ended

070224 17:52:53 mysqld started
070224 17:52:53 [Warning] One can only use the --user switch if running as root

070224 17:52:53 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=zmail-bin' to avoid this problem.
070224 17:52:55 InnoDB: Started; log sequence number 0 242054503
070224 17:52:55 [Note] /opt/zimbra/mysql/libexec/mysqld: ready for connections.
Version: '5.0.26-log' socket: '/opt/zimbra/db/mysql.sock' port: 7306 Source distribution
A mysqld process already exists at Wed Feb 28 07:46:15 CET 2007
Reply With Quote