: problems with INNODB tables
Thanks for your answer. I read http://mysql.rjweb.org/doc.php/memory
where it tells you to do one thing if using MYIASM tables and another
if using INNODB tables. We are using both. Any suggestions?
Thanks for any help.
Malki Cymbalista
Webmaster, Weizmann Institute
...@weizmann.ac.il
08-9343036
-Original Message-
From: Rick James [mailto:rja...@yahoo-inc.com]
Sent: Monday, April 23, 2012 9:42 PM
To: Andrés Tello; Malka Cymbalista
Cc: mysql@lists.mysql.com; Shlomit Afgin; Ronen Hayun
Subject: RE: problems with INNODB tables
Check your memory usage
Cymbalista
Cc: mysql@lists.mysql.com; Shlomit Afgin; Ronen Hayun
Subject: RE: problems with INNODB tables
Check your memory usage according to
http://mysql.rjweb.org/doc.php/memory
-Original Message-
From: Andrés Tello [mailto:mr.crip...@gmail.com]
Sent: Monday, April 23, 2012 9:00
Weird, I use a lot Innodb, and no issue, I even kill bravely the mysql
process with pkill -9 -f mysql
Y suppose the way drupal is being programed.
PHP open and closes database connections each time a webpage with db access
is issued.
When a php exceution ends and the apache webserver have
Check your memory usage according to
http://mysql.rjweb.org/doc.php/memory
-Original Message-
From: Andrés Tello [mailto:mr.crip...@gmail.com]
Sent: Monday, April 23, 2012 9:00 AM
To: Malka Cymbalista
Cc: mysql@lists.mysql.com; Shlomit Afgin; Ronen Hayun
Subject: Re: problems
Harrison wrote:
Hi, sorry about the long delay in the reply. I will be away for the next
2 weeks, but I will follow this thread if anything new comes up.
Hi,
A few more ideas you can try:
1. SET UNIQUE_CHECKS=0;
You have a unique key that is quite large (model, id name). If
you know the
any change,
but I don't expect it.
Luc
-Original Message-
From: Luc Charland [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 03, 2004 7:54 PM
To: [EMAIL PROTECTED]
Subject: Insert problems with InnoDB (big table)
We are evaluating the replacement of a Sybase database with MySQL
Hi Frank,
you actually got me doubting here. We don't use mysql client, but I made
sure that autocommit was turned off.
I double checked (with select count(*) from smalltest) to see the
inserts were in fact commited by chunk of 100,000 and not one by one,
and it was.
We still see exactly the
[EMAIL PROTECTED] wrote:
Estimado Luc,
Con fecha jueves 5 de agosto de 2004, 11.07.23, escribió:
Did you try disable index table? When you import millon of records
there is an overload indexing it. First import and then create your
index or:
ALTER TABLE tb_name DISABLE KEYS;
import data...
Hi,
A few more ideas you can try:
1. SET UNIQUE_CHECKS=0;
You have a unique key that is quite large (model, id name). If you
know the data is already unique (ie. importing from another data
source), then this can speed up the import *a lot*.
2. SET FOREIGN_KEY_CHECKS=0;
You didn't mention
Luc,
do you use the mysql client for the insert operations?
And is autocommit set to yes?
Then the answer is:
turn off autocommit mode and commit every high number but not too high
to grow InnoDB's transaction handling resources too big rows.
Commit every 100,000 rows for example.
The speeds up
Are you disabling autocommit before doing the inserts? And committing
after all inserts are complete?
-Original Message-
From: Luc Charland [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 03, 2004 7:54 PM
To: [EMAIL PROTECTED]
Subject: Insert problems with InnoDB (big table)
We
?
-Original Message-
From: Luc Charland [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 03, 2004 7:54 PM
To: [EMAIL PROTECTED]
Subject: Insert problems with InnoDB (big table)
We are evaluating the replacement of a Sybase database with MySQL. The
databases are 60+GB, containing more than 100
We are evaluating the replacement of a Sybase database with MySQL. The
databases are 60+GB, containing more than 100 tables.
Since we need transactions, that implies InnoDB. We were happy with the
early results, but we hit a major roadblock when trying to import the
biggest table (20+GB, with
[EMAIL PROTECTED]
Newsgroups: mailing.database.myodbc
Sent: Friday, December 12, 2003 2:53 AM
Subject: [ MySQL: Problems with Innodb ]
--=_NextPart_000_000C_01C3BFEE.891285C0
Content-Type: multipart/alternative;
boundary==_NextPart_001_000D_01C3BFEE.891719A0
Hi,
I
have a problem and would like a help.
I
copied a mysql datadir to another place (backup of datadir), but when start up
mysql server with datadir it's crash.
See
below, trace of logfile:
031211 13:28:01 mysqld
started031211 13:28:01 InnoDB: Database was not shut down
I use both kinds of tables in my softawares, MyISAM and InnoDB, but since
I started trying using InnoDb, some problems with that kind of thable has
been occured.
Sometimes when I try to connect to an InnoDB, the server answers that the
table does not exist, but it's there, I can see it in my
Mark, Steff,
- Original Message -
From: Mark Matthews [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, February 12, 2003 3:09 AM
Subject: Re: Transaction problems using InnoDB, not locked with LOCKTABLES
-BEGIN PGP SIGNED MESSAGE
: Heikki Tuuri [EMAIL PROTECTED]
To: Mark Matthews [EMAIL PROTECTED],
[EMAIL PROTECTED]
Copies to: [EMAIL PROTECTED]
Subject:Re: Transaction problems using InnoDB, not
locked with LOCKTABLES
Date sent: Thu, 13 Feb 2003 16
Steff,
- Original Message -
From: [EMAIL PROTECTED]
To: Heikki Tuuri [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, February 13, 2003 7:21 PM
Subject: Re: Transaction problems using InnoDB, not locked with LOCKTABLES
Heikki,
Thanks for the reply.
My confusion
be greatly appreciated.
Thanks
Steff
On 13 Feb 2003 at 20:03, Heikki Tuuri wrote:
From: Heikki Tuuri [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Copies to: [EMAIL PROTECTED]
Subject:Re: Transaction problems using InnoDB, not
locked
SET autocommit=1
- Original Message -
From: [EMAIL PROTECTED]
To: Heikki Tuuri [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Thursday, February 13, 2003 8:54 PM
Subject: Re: Transaction problems using InnoDB, not locked with LOCKTABLES
Heikki
PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject:Re: Transaction problems using InnoDB, not
locked with LOCKTABLES
Date sent: Thu, 13 Feb 2003 21:59:22 +0200
Steff,
a note on terminology: every query inside InnoDB always happens inside
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
Heikki,
The application which is having this problem is used to read an
XML document and update a database. The application is part of a
website, so there are always other interactions with the database
while the
:Re: Transaction problems using InnoDB, not
locked with LOCKTABLES
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
Heikki,
The application which is having this problem is used to read an
XML document and update a database. The application
Hello,
We are experiencing severe problems when running MySql with
INNODB in a production environment. Applications which work
fine under light load fail when under production load.
Our MySql environment is as follows:
OS Platform: Windows 2000 Service Pack 2
Machine description:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
Hello,
We are experiencing severe problems when running MySql with
INNODB in a production environment. Applications which work
fine under light load fail when under production load.
Our MySql environment is as
sent: Tue, 11 Feb 2003 19:09:16 -0600
From: Mark Matthews [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Copies to: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject:Re: Transaction problems using InnoDB, not
locked
On Tue, 4 Feb 2003, Kees Hoekzema wrote:
I had the same problem, it went on until I had 44G of InnoDB space, with only
4G free. After getting tired of having to increase the number of files every
week, I decided to dump all data with mysqldump, remove the files+ logs and
recreate them. After
Kees Hoekzema wrote:
Hello,
On Tuesday 04 February 2003 14:46, Grover Cussi N. wrote:
restore to the original size ?, I see that the tendence of the innodb
tables is to grow, and grow, and never will reduce the size, it is
posible to control this?
I had the same problem, it went on
Hello,
On Tuesday 04 February 2003 14:46, Grover Cussi N. wrote:
restore to the original size ?, I see that the tendence of the innodb
tables is to grow, and grow, and never will reduce the size, it is
posible to control this?
I had the same problem, it went on until I had 44G of InnoDB
Hello!
I have a problem with the innodb files, Well I have a database with a big
table with more than 3 milon of register, beside I have other databases
that haz different size. My innodb file grow up to 1 G, I make a
sql sentence, delete from from big_table, and the size of the innodb
Grover,
I am carbon copying this to [EMAIL PROTECTED]
- Original Message -
From: Grover Cussi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 01, 2003 2:16 AM
Subject: Problems with innodb
Hello!
I have various databases, one has a table with more than 3 millions
Hello!!
I have various databases, one with a table with more than 3 millions
of registers, and other has 250 MB, 50MB. My ibdata1 grow to more than
1 G, well I do not want my big database, I drop the database but the
size of the ibdata continues with the same size, what can I do?? I
waant my
So I have been reading a lot lately about replication but I can't find a
good summary/explanation of MySQL's replication features regarding InnoDB
tables and how their transactional properties may cause problems in
replication.
I have seen suggestions that InnoDB tables should be converted to
Kris,
- Original Message -
From: Krzysztof Karski [EMAIL PROTECTED]
Newsgroups: mailing.database.mysql
Sent: Tuesday, January 21, 2003 11:35 AM
Subject: replication problems with InnoDB tables...?
So I have been reading a lot lately about replication but I can't find a
good summary
Hello Mark,
thanks for your answer. In fact the mysql shell where I update the row is
using AUTOCOMMIT=1.
Even after I issue a COMMIT manually the changes are not seen by the
application.
What I dont understand is that the program doing a SELECT has to issue an
COMMIT to have all data available.
Hi Stefan,
Does the second shell actually perform those changes? In this case, I
assume
it's got something to do with the isolation level / consistent read in
InnoDB tables. shell1 sees all its changes immediately, shell2 (the
application) has just a snapshot of the data at the time it
Heri,
H. Steuer schrieb:
Hi Stefan,
Does the second shell actually perform those changes? In this case, I
assume
it's got something to do with the isolation level / consistent read in
InnoDB tables. shell1 sees all its changes immediately, shell2 (the
application) has just a
Heri,
- Original Message -
From: H. Steuer [EMAIL PROTECTED]
Newsgroups: mailing.database.mysql
Sent: Tuesday, December 03, 2002 11:49 AM
Subject: Re: C API problems with InnoDB
Hello Mark,
thanks for your answer. In fact the mysql shell where I update the row is
using AUTOCOMMIT=1
Hello MySQL users,
I have a weired issue using the MySQL C API and InnoDB tables.
An application polls a database every 30 seconds. When the application
starts everything seems to be fine.
During the running of the application i change some rows, but the
application itself doesnt see the changes
7970948-0 Fax: +49 30 7970948-3
- Original Message -
From: H. Steuer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, December 02, 2002 10:29 PM
Subject: C API problems with InnoDB
Hello MySQL users,
I have a weired issue using the MySQL C API and InnoDB tables.
An application polls
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
H. Steuer wrote:
Hello MySQL users,
I have a weired issue using the MySQL C API and InnoDB tables.
An application polls a database every 30 seconds. When the application
starts everything seems to be fine.
During the running of the application i
Marek,
please address these general questions to [EMAIL PROTECTED]
- Original Message -
From: Marek Lewczuk [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 29, 2002 10:04 AM
Subject: Problems with InnoDB
Hello!!
I have read some post about this problem
Hi Heikki,
one more question please about innodb_flush_log_at_trx_commit: if there
was some way of increasing the delay between log flushes more than 1 sec,
can you estimate will it bring any real effect in performance? I know
it'll raise the risk of losing some last transactions if something
Alexander,
- Original Message -
From: Varshavchick Alexander [EMAIL PROTECTED]
To: 'Heikki Tuuri' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 06, 2002 10:08 AM
Subject: RE: Performance Problems with InnoDB Row Level Locking...
Hi Heikki,
one more question please
Joe,
- Original Message -
From: Joe Shear [EMAIL PROTECTED]
To: Heikki Tuuri [EMAIL PROTECTED]
Sent: Friday, September 06, 2002 2:13 AM
Subject: Re: Performance Problems with InnoDB Row Level Locking...
Hi,
On a side note, are there any plans to backport the spurious insert
deadlock
PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Performance Problems with InnoDB Row Level Locking...
Alexander,
- Original Message -
From: Varshavchick Alexander [EMAIL PROTECTED]
To: 'Heikki Tuuri' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 06, 2002 10:08 AM
Alex,
- Original Message -
From: Varshavchick Alexander [EMAIL PROTECTED]
To: Heikki Tuuri [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 06, 2002 11:49 AM
Subject: Re: Performance Problems with InnoDB Row Level Locking...
Heikki, thank you for the answer. So
Background:
I've developed a simplistic Perl program to test database performance with
concurrent session queries. The queries involve inserts, updates, and
deletes in order to test database performance in an OLTP mult-user ACID
compliant scenario. Obviously this is not a real world test but it
Heikki, one little question - is it a mistype, or can a flush log interval
duration be controlled by this option? The value should only be 0 or 1 as
the documentation says...
On Thu, 5 Sep 2002, Heikki Tuuri wrote:
You can try setting
innodb_flush_log_at_trx_commit=2
if you can afford
Alexander,
- Original Message -
From: Varshavchick Alexander [EMAIL PROTECTED]
To: Heikki Tuuri [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, September 05, 2002 6:51 PM
Subject: Re: Performance Problems with InnoDB Row Level Locking...
Heikki, one little question
eagerly awaiting your reply.
Respectfully,
Steve Orr
-Original Message-
From: Heikki Tuuri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 05, 2002 9:05 AM
To: [EMAIL PROTECTED]
Subject: Re: Performance Problems with InnoDB Row Level Locking...
Steve,
- Original Message
Steve,
- Original Message -
From: Orr, Steve [EMAIL PROTECTED]
To: 'Heikki Tuuri' [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, September 05, 2002 9:49 PM
Subject: RE: Performance Problems with InnoDB Row Level Locking...
Hello again Heikki and thanks for your informative reply
]
To: Orr, Steve [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, September 05, 2002 10:30 PM
Subject: Re: Performance Problems with InnoDB Row Level Locking...
Steve,
- Original Message -
From: Orr, Steve [EMAIL PROTECTED]
To: 'Heikki Tuuri' [EMAIL PROTECTED]; [EMAIL PROTECTED
Steve,
- Original Message -
From: Orr, Steve [EMAIL PROTECTED]
To: 'Heikki Tuuri' [EMAIL PROTECTED]
Sent: Thursday, September 05, 2002 11:04 PM
Subject: RE: Performance Problems with InnoDB Row Level Locking...
Heikki,
You wrote...
You are getting so many deadlocks that some
: Heikki Tuuri [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 05, 2002 2:54 PM
To: Orr, Steve
Cc: [EMAIL PROTECTED]
Subject: Re: Performance Problems with InnoDB Row Level Locking...
Steve,
- Original Message -
From: Orr, Steve [EMAIL PROTECTED]
To: 'Heikki Tuuri' [EMAIL PROTECTED
Steve,
- Original Message -
From: Orr, Steve [EMAIL PROTECTED]
To: 'Heikki Tuuri' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 06, 2002 1:23 AM
Subject: RE: Performance Problems with InnoDB Row Level Locking...
Heikki,
Next-key locking in InnoDB allows you
58 matches
Mail list logo