Memory Usage.
How can I know how memory is being used by Mysql? I have 32GB Ram, but I can't make mysql to use more than 12GB Ram , and even that I have tables over 40GB... Thanks! xD
Re: Memory Usage.
Am 25.04.2011 16:24, schrieb Andrés Tello: How can I know how memory is being used by Mysql? I have 32GB Ram, but I can't make mysql to use more than 12GB Ram , and even that I have tables over 40GB... Thanks! xD depends on storage-engine (myisam or innodb), buffer-sizes, size of the query-cache, size of keys - the target is not to use the full memory, the target is use available momory wise search for mysqltuner.pl very interesting is the memory per connection (depends on many buffer-params) becuase with a little mistake the possible max usage can easily be some hundret GB! [--] Up for: 17d 21h 53m 13s (39M q [25.329 qps], 132K conn, TX: 60B, RX: 19B) [--] Reads / Writes: 67% / 33% [--] Total buffers: 6.1G global + 1.2M per thread (500 max threads) [OK] Maximum possible memory usage: 6.7G (66% of installed RAM) [OK] Slow queries: 0% (13/39M) [OK] Highest usage of available connections: 72% (362/500) [OK] Key buffer size / total MyISAM indexes: 128.0M/74.1M [OK] Key buffer hit rate: 97.6% (109M cached / 2M reads) [OK] Query cache efficiency: 73.8% (23M cached / 32M selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 0% (247 temp sorts / 731K sorts) [OK] Temporary tables created on disk: 0% (1K on disk / 1M total) [OK] Thread cache hit rate: 99% (362 created / 132K connections) [!!] Table cache hit rate: 8% (131 open / 1K opened) [OK] Open file limit used: 0% (67/30K) [OK] Table locks acquired immediately: 99% (18M immediate / 18M locks) [!!] InnoDB data size / buffer pool: 16.6G/5.0G -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature
RE: mysql deal with specail character problem
From: 赵琦 [mailto:tyzha...@gmail.com] Sent: Thursday, April 21, 2011 9:19 PM To: Jerry Schwartz Cc: Johan De Meersman; sstap...@mnsi.net; mysql Subject: Re: mysql deal with specail character problem thanks for reply! The charater set is latin1,and the key field is mangled by the email client. [JS When you say that the character set is latin1, do you mean that the database is using latin1? That would definitely cause your problem, because the data would be truncated at the first character that isn’t latin1. Here’s a simple experiment: Add one row to your table, and then SELECT LENGTH() of your field. What comes back? Regards, Jerry Schwartz Global Information Incorporated 195 Farmington Ave. Farmington, CT 06032 860.674.8796 / FAX: 860.674.8341 E-mail: je...@gii.co.jp Web site: www.the-infoshop.com http://www.the-infoshop.com/ I up load the actual character of '?' to the attachment. 2011/4/22 Jerry Schwartz je...@gii.co.jp -Original Message- From: Johan De Meersman [mailto:vegiv...@tuxera.be] Sent: Thursday, April 21, 2011 9:56 AM To: sstap...@mnsi.net Cc: ??; mysql; Jerry Schwartz Subject: Re: mysql deal with specail character problem - Original Message - From: Steve Staples sstap...@mnsi.net Doesn't the '?-1-1' mean that it's a joined key? so the 3 That's what I tought, but I *can* see the characters he's typed, and the last of what you see as ? is definitely different. [JS] That's because his font (or e-mail client) mangled the text, and so his reply wasn't legible. Our main office is in Japan, so I go through this all the time. Regards, Jerry Schwartz Global Information Incorporated 195 Farmington Ave. Farmington, CT 06032 860.674.8796 / FAX: 860.674.8341 E-mail: je...@gii.co.jp Web site: www.the-infoshop.com http://www.the-infoshop.com/ -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel
LEFT JOIN and WHERE: identical or not and what is better?
Hello everyone, Sorry for my beginner question. Actually I have been using MySql for a long time but I just start using some advanced things (earlier I accomplished those tasks with PHP), so I will be asking stupid questions, please bear with me. Here is the first one. We have two queries: SELECT `blogs`.* FROM `Blogs` LEFT JOIN `Users` ON `Blogs`.`UserId`=`Users`.`Id`; and the following one: SELECT `Blogs`.* FROM `Blogs`, `Users` WHERE `Blogs`.`UserId`=`Users`.`Id`; 1. Are they identical? 2. Which is better (faster, more optimal, more kosher, I mean, better style...)? Thanks! -- With best regards from Ukraine, Andre Skype: Francophile Twitter: http://twitter.com/m_elensule Facebook: http://facebook.com/menelion -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
RE: Memory Usage.
-Original Message- From: Andrés Tello [mailto:mr.crip...@gmail.com] Sent: Monday, April 25, 2011 10:24 AM To: Mailing-List mysql Subject: Memory Usage. How can I know how memory is being used by Mysql? I have 32GB Ram, but I can't make mysql to use more than 12GB Ram , and even that I have tables over 40GB... Thanks! xD [JS] The amount of memory used will be the smallest of 1. Available physical memory 2. Usable memory (this is a limitation built into the code design, both at OS level and at the MySQL/storage engine level) 3. Allowed memory (a configuration setting) 4. Needed memory 1 and 2 are usually easy to find out. When it comes to 4, things get very murky. As someone else said, the goal is to use memory wisely. That means finding a trade-off between efficient use of memory and speed. Once you understand and make some choices with 4, you can go back and tinker with 3. As any performance consultant worth his salt will tell you, It depends. Regards, Jerry Schwartz Global Information Incorporated 195 Farmington Ave. Farmington, CT 06032 860.674.8796 / FAX: 860.674.8341 E-mail: je...@gii.co.jp Web site: www.the-infoshop.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: LEFT JOIN and WHERE: identical or not and what is better?
'where' is a filter. You're limiting records based on a criterion. 'on' is used for joining. On Mon, Apr 25, 2011 at 10:42 AM, Andre Polykanine an...@oire.org wrote: Hello everyone, Sorry for my beginner question. Actually I have been using MySql for a long time but I just start using some advanced things (earlier I accomplished those tasks with PHP), so I will be asking stupid questions, please bear with me. Here is the first one. We have two queries: SELECT `blogs`.* FROM `Blogs` LEFT JOIN `Users` ON `Blogs`.`UserId`=`Users`.`Id`; and the following one: SELECT `Blogs`.* FROM `Blogs`, `Users` WHERE `Blogs`.`UserId`=`Users`.`Id`; 1. Are they identical? 2. Which is better (faster, more optimal, more kosher, I mean, better style...)? Thanks! -- With best regards from Ukraine, Andre Skype: Francophile Twitter: http://twitter.com/m_elensule Facebook: http://facebook.com/menelion -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=mmal...@gmail.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: LEFT JOIN and WHERE: identical or not and what is better?
I can be wrong about that, but I think the difference between them should be irrelevant so it makes me think about a paranoiac thought. For me, the only difference is: Chose the one you feel better to understand your code. Am I wrong or not? -- João Cândido de Souza Neto Andre Polykanine an...@oire.org escreveu na mensagem news:199779304.20110425174...@oire.org... Hello everyone, Sorry for my beginner question. Actually I have been using MySql for a long time but I just start using some advanced things (earlier I accomplished those tasks with PHP), so I will be asking stupid questions, please bear with me. Here is the first one. We have two queries: SELECT `blogs`.* FROM `Blogs` LEFT JOIN `Users` ON `Blogs`.`UserId`=`Users`.`Id`; and the following one: SELECT `Blogs`.* FROM `Blogs`, `Users` WHERE `Blogs`.`UserId`=`Users`.`Id`; 1. Are they identical? 2. Which is better (faster, more optimal, more kosher, I mean, better style...)? Thanks! -- With best regards from Ukraine, Andre Skype: Francophile Twitter: http://twitter.com/m_elensule Facebook: http://facebook.com/menelion -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: LEFT JOIN and WHERE: identical or not and what is better?
The only difference once MySQL parses these two queries is the first one is a LEFT JOIN, which will produce all records from the blogs table even if there is no matching record in the users table. The second query produces an INNER JOIN which means only rows with matching records in both tables will be returned. Which one is faster? Probably the second since NULLs do not have to be considered -- probably not much faster though. Which one is better? That'll depend on your needs, if you only need records from both tables that have a matching row in the other, the second is better. If you need all blogs, even those without a matching user (can that even occur?), the first one is better. I prefer to write the INNER JOIN out though because it leaves my WHERE clause to do filtering. JW On Mon, Apr 25, 2011 at 9:42 AM, Andre Polykanine an...@oire.org wrote: Hello everyone, Sorry for my beginner question. Actually I have been using MySql for a long time but I just start using some advanced things (earlier I accomplished those tasks with PHP), so I will be asking stupid questions, please bear with me. Here is the first one. We have two queries: SELECT `blogs`.* FROM `Blogs` LEFT JOIN `Users` ON `Blogs`.`UserId`=`Users`.`Id`; and the following one: SELECT `Blogs`.* FROM `Blogs`, `Users` WHERE `Blogs`.`UserId`=`Users`.`Id`; 1. Are they identical? 2. Which is better (faster, more optimal, more kosher, I mean, better style...)? Thanks! -- With best regards from Ukraine, Andre Skype: Francophile Twitter: http://twitter.com/m_elensule Facebook: http://facebook.com/menelion -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=joh...@pixelated.net -- - Johnny Withers 601.209.4985 joh...@pixelated.net
Are those patches already includes in 5.5 community version?
For pathces like : *EBay Patches (5.0)* have included: - variable length memory storage engine - pool of threads - Virtual columns and others like *Google Patches (5.0 5.1)* included improvements in : - statistics/monitoring - lock contention - binlog - malloc() - filesorts - innodb I/O and wait statistics - SHOW …STATISTICS statements - smp scalability - I/O scalability - semisync replication - many more *Percona Patches (5.0)* focus on - statistics/monitoring - performance/scalability - buffer pool content/mutexes - microslow patch Thx -- Regards Zhu Chao
Re: LEFT JOIN and WHERE: identical or not and what is better?
Hi Andre, everybody! Andre Polykanine wrote: Hello everyone, Sorry for my beginner question. Actually I have been using MySql for a long time but I just start using some advanced things (earlier I accomplished those tasks with PHP), so I will be asking stupid questions, please bear with me. Here is the first one. We have two queries: SELECT `blogs`.* FROM `Blogs` LEFT JOIN `Users` ON `Blogs`.`UserId`=`Users`.`Id`; and the following one: SELECT `Blogs`.* FROM `Blogs`, `Users` WHERE `Blogs`.`UserId`=`Users`.`Id`; 1. Are they identical? 2. Which is better (faster, more optimal, more kosher, I mean, better style...)? In your subject line, you are mixing unrelated things: - LEFT JOIN is an alternative to INNER JOIN. It tell the database to return not only matching row combinations but also those where the first (left-hand) table has a row with a NULL column. - ON is an alternative to WHERE. For both aspects, the manual has more information than I will be able to think of in this mail. So the real difference between your statements is not LEFT JOIN vs WHERE, or ON vs WHERE, it is LEFT JOIN vs inner join. It will become important if you have rows in table Blogs whose column UserId holds NULL rather than any definite value. To understand that, you will have to read about NULL and the three-valued logic of SQL (whose comparisons can return true, false, and unknown). In general, an inner join should be faster - but who cares? SQL statements must be coded for correctness first, not for speed - and that will determine your choice of LEFT JOIN vs inner join. Tuning and optimization come later (in priority). The same holds for style etc: Clean programming is nice (and helpful in understanding and maintenance), but correctness comes first. Regards, Joerg -- Joerg Bruehe, MySQL Build Team, joerg.bru...@oracle.com ORACLE Deutschland B.V. Co. KG, Komturstrasse 18a, D-12099 Berlin Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven Amtsgericht Muenchen: HRA 95603 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Are those patches already includes in 5.5 community version?
Just looked at version 5.5/5.6 document: http://dev.mysql.com/doc/refman/5.5/en/memory-storage-engine.html at least the variable length memory patch is not included, i guess same with others; It is disappointed MySQL is not including those into the 5.5/5.6 version; BTW: i was reading http://ronaldbradford.com/blog/beyond-mysql-ga-patches-storage-engines-forks-and-pre-releases-fosdem-2010-2010-02-11/previously; On Tue, Apr 26, 2011 at 12:34 AM, Zhu,Chao zhuc...@gmail.com wrote: For pathces like : *EBay Patches (5.0)* have included: - variable length memory storage engine - pool of threads - Virtual columns and others like *Google Patches (5.0 5.1)* included improvements in : - statistics/monitoring - lock contention - binlog - malloc() - filesorts - innodb I/O and wait statistics - SHOW …STATISTICS statements - smp scalability - I/O scalability - semisync replication - many more *Percona Patches (5.0)* focus on - statistics/monitoring - performance/scalability - buffer pool content/mutexes - microslow patch Thx -- Regards Zhu Chao -- Regards Zhu Chao
Join based upon LIKE
I have to match lists of new publications against our database, so that I can
replace the existing publications in our catalog. For example,
The UK Market for Puppies in February 2011
would be a replacement for
The UK Market for Puppies in December 2010
Unfortunately, the publishers aren't particularly careful with their titles.
One might even say they are perverse. I am likely to get
UK Market: Puppies - Feb 2011
as replacement for
The UK Market for Puppies in December 2010
You can see that a straight match by title is not going to work.
Here's what I've been doing:
=
SET @PUBID = (SELECT pub.pub_id FROM pub WHERE pub.pub_code = 'GD');
CREATE TEMPORARY TABLE new_titles (
new_title VARCHAR(255), INDEX (new_title),
new_title_like VARCHAR(255), INDEX (new_title_like)
);
INSERT INTO new_titles
VALUES
('Alternative Energy Monthly Deal Analysis - MA and Investment Trends, April
2011', 'Alternative Energy Monthly Deal Analysis%MA%Investment Trends%'),
('Asia Pacific Propylene Industry Outlook to 2015 - Market Size, Company
Share, Price Trends, Capacity Forecasts of All Active and Planned Plants',
'Asia Pacific Propylene Industry Outlook to%Market Size%Company Share%Price
Trends%Capacity Forecasts of All Active%Planned Plants'),
...
('Underground Gas Storage Industry Outlook in North America, 2011 - Details of
All Operating and Planned Gas Storage Sites to 2014', 'Underground Gas Storage
Industry Outlook%North America%Details of All Operating%Planned Gas Storage
Sites to%'),
('Uveitis Therapeutics - Pipeline Assessment and Market Forecasts to 2017',
'Uveitis Therapeutics%Pipeline Assessment%Market Forecasts to%');
SELECT prod.prod_title AS `Title IN Database`,
new_titles.new_title AS `Title IN Feed`,
prod.prod_num AS `ID`
FROM new_titles JOIN prod ON prod.prod_title LIKE (new_titles.new_title_like)
AND prod.pub_id = @PUBID AND prod.prod_discont = 0
ORDER BY new_titles.new_title;
==
(I've written code that substitutes % for certain strings that I specify,
and there is some trial and error involved.)
Here's how MySQL handles that SELECT:
*** 1. row ***
id: 1
select_type: SIMPLE
table: new_titles
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 47
Extra: Using filesort
*** 2. row ***
id: 1
select_type: SIMPLE
table: prod
type: ref
possible_keys: pub_id
key: pub_id
key_len: 48
ref: const
rows: 19607
Extra: Using where
=
Here's the important part of the table `prod`:
=
Table: prod
Create Table: CREATE TABLE `prod` (
`prod_id` varchar(15) NOT NULL DEFAULT '',
`prod_num` mediumint(6) unsigned DEFAULT NULL,
`prod_title` varchar(255) DEFAULT NULL,
`prod_type` varchar(2) DEFAULT NULL,
`prod_vat_pct` decimal(5,2) DEFAULT NULL,
`prod_discont` tinyint(1) DEFAULT NULL,
`prod_replacing` mediumint(6) unsigned DEFAULT NULL,
`prod_replaced_by` mediumint(6) unsigned DEFAULT NULL,
`prod_ready` tinyint(1) DEFAULT NULL,
`pub_id` varchar(15) DEFAULT NULL,
...
PRIMARY KEY (`prod_id`),
UNIQUE KEY `prod_num` (`prod_num`),
KEY `prod_pub_prod_id` (`prod_pub_prod_id`),
KEY `pub_id` (`pub_id`),
KEY `prod_title` (`prod_title`),
FULLTEXT KEY `prod_title_fulltext` (`prod_title`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8
=
This works reasonably well for a small number (perhaps 200-300) of new
products; but now I've been handed a list of over 15000 to stuff into the
table `new_titles`! This motivates me to wonder if there is a better way,
since I expect this to take a very long time.
Suggestions?
Regards,
Jerry Schwartz
Global Information Incorporated
195 Farmington Ave.
Farmington, CT 06032
860.674.8796 / FAX: 860.674.8341
E-mail: je...@gii.co.jp
Web site: www.the-infoshop.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
RE: WHERE does not work on calculated view field - Found word(s) list error in the Text body
Hello Daniel,
My best advice is to not use a custom MySQL function in a view when the
parameter to that function
is a column or expression that has the potential to result in NULL because of
being on the right side
of a left outer join (or the left side of a right outer join). This
particular set of circumstances
seems to cause MySQL to treat the resulting expression as unknown when used
in a where clause on the view
itself - such that any use of the expression in the where clause will evaluate
to unknown/false.
As a workaround - this view for example behaves as expected:
CREATE VIEW `myview2` AS
SELECT a.*, IF(b.`Name` IS NULL, '', b.`Name`) AS `TypeName`
FROM `mytable` a
LEFT JOIN `types` b ON a.`Type` = b.`ID`;
Thanks
lm
-Original Message-
From: Daniel Kraft [mailto:d...@domob.eu]
Sent: Sunday, April 24, 2011 2:03 PM
To: Larry McGhaw
Cc: Daevid Vincent; mysql@lists.mysql.com
Subject: Re: WHERE does not work on calculated view field - Found word(s) list
error in the Text body
On 04/22/11 22:41, Larry McGhaw wrote:
It does appear to be some type of bug to me.
Hm... do you have an idea how to work around this bug then?
Yours,
Daniel
Clearly from the select, the Typename field is not null, as shown here.
mysql SELECT *, TypeName Is NULL, TypeName IS NOT NULL FROM `myview`;
++--+--+--+--+
| ID | Type | TypeName | TypeName Is NULL | TypeName IS NOT NULL |
++--+--+--+--+
| 1 | NULL | |0 |1 |
++--+--+--+--+
1 row in set (0.00 sec)
But when referenced in the where clause in any manner, no results are
returned.
mysql SELECT *, TypeName Is NULL, TypeName IS NOT NULL FROM `myview` where
TYPE
NAME IS NOT NULL;
Empty set (0.00 sec)
-Original Message-
From: Daniel Kraft [mailto:d...@domob.eu]
Sent: Friday, April 22, 2011 1:05 PM
To: Daevid Vincent
Cc: mysql@lists.mysql.com
Subject: Re: WHERE does not work on calculated view field - Found word(s)
list error in the Text body
Hi,
thanks for the fast reply!
On 04/22/11 21:39, Daevid Vincent wrote:
DROP DATABASE `test`;
CREATE DATABASE `test`;
USE `test`;
CREATE TABLE `mytable`
(`ID` SERIAL,
`Type` INTEGER UNSIGNED NULL,
PRIMARY KEY (`ID`));
INSERT INTO `mytable` (`Type`) VALUES (NULL);
CREATE TABLE `types`
(`ID` SERIAL,
`Name` TEXT NOT NULL,
PRIMARY KEY (`ID`));
INSERT INTO `types` (`Name`) VALUES ('Type A'), ('Type B');
DELIMITER |
CREATE FUNCTION `EMPTY_STRING` (value TEXT)
RETURNS TEXT
DETERMINISTIC
BEGIN
RETURN IF(value IS NULL, '', value);
END|
DELIMITER ;
CREATE VIEW `myview` AS
SELECT a.*, EMPTY_STRING(b.`Name`) AS `TypeName`
FROM `mytable` a
LEFT JOIN `types` b ON a.`Type` = b.`ID`;
SELECT COUNT(*) FROM `myview` WHERE `TypeName` IS NULL;
SELECT COUNT(*) FROM `myview` WHERE `TypeName` IS NOT NULL;
SELECT COUNT(*) FROM `myview` WHERE `TypeName` LIKE '%';
(I tried to simplify my problem as far as possible.) When I run this
against MySQL 5.0.24a, I get three times 0 as output from the SELECTs
at the end -- shouldn't at least one of them match the single row?
(Preferably first and third ones.)
What am I doing wrong here? I have no clue what's going on... Thanks a
lot!
Try this maybe:
SELECT COUNT(*) FROM `myview` HAVING `TypeName` IS NULL;
SELECT COUNT(*) FROM `myview` HAVING `TypeName` IS NOT NULL;
SELECT COUNT(*) FROM `myview` HAVING `TypeName` LIKE '%';
When I try those, I get:
ERROR 1054 (42S22) at line 35: Unknown column 'TypeName' in 'having clause'
What would be the difference? (I've never used HAVING before.)
Yours,
Daniel
--
http://www.pro-vegan.info/
--
Done: Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: WHERE does not work on calculated view field - Found word(s) list error in the Text body
Hi, On 04/25/11 20:45, Larry McGhaw wrote: My best advice is to not use a custom MySQL function in a view when the parameter to that function is a column or expression that has the potential to result in NULL because of being on the right side of a left outer join (or the left side of a right outer join). This particular set of circumstances seems to cause MySQL to treat the resulting expression as unknown when used in a where clause on the view itself - such that any use of the expression in the where clause will evaluate to unknown/false. As a workaround - this view for example behaves as expected: CREATE VIEW `myview2` AS SELECT a.*, IF(b.`Name` IS NULL, '', b.`Name`) AS `TypeName` FROM `mytable` a LEFT JOIN `types` b ON a.`Type` = b.`ID`; now you mention it, it seems obvious -- but I didn't think about that solution before... But 'inlining' my function this way seems to fix the problem also in my real application. Thanks a lot! Yours, Daniel -- http://www.pro-vegan.info/ -- Done: Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Mon-Pri -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Practical connection limits MySQL 5.1/5.5
eBay once developed a patch for pooled threads, on top of 5.0, to resolve this kind of issue so they can support 10k+ sessions(massive amount of application need to talk to those mysql). Not sure whether they are merged into main version though. Best regards Zhuchao 在 2011-4-14，17:59，Reindl Harald h.rei...@thelounge.net 写道： Am 14.04.2011 11:50, schrieb Johan De Meersman: - Original Message - From: Reindl Harald h.rei...@thelounge.net even if you have enough memory why will you throw it away for a unusual connection count instead use the RAm for innodb-buffer-pool, query-cache, key-buffers? Maybe the application doesn't have support for connection pooling and can't be easily replaced. http://sqlrelay.sourceforge.net/sqlrelay/gettingstarted/mysql.html Maybe there's just that much clients instead of a central service Maybe the OP could clarify what he really does Maybe there's not just a single application that uses that database. http://sqlrelay.sourceforge.net/sqlrelay/gettingstarted/mysql.html As usual, Harald, you fail to realise that your experience does not encompass the whole of human civilisation. as usual people have questions without any information what they really do You seem to have a good technical background, but it might be useful to learn to consider problems from the point of view of the people who have them, at times. It tends to be a much appreciated skill in the real world. this is your point of view, ok my point of view is instead having headaches about how many connections are possible without problems to consider how many connections are really needed and without my.cnf (buffer settings), any information about the workload of the applications the whole question does not make sense -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
