On 5/15/07, Micah Stevens <[EMAIL PROTECTED]> wrote:
I think you may be able to get around this by using multiple key
buffers? (MySQL 4.1 or later)
key buffers caches only index data and they dont help with sorting like
sort_buffer. they dont impact innodb engine. even while using multiple key
I think you may be able to get around this by using multiple key
buffers? (MySQL 4.1 or later)
-Micah
On 05/15/2007 01:24 AM, Christoph Klünter wrote:
Hi List,
We have a mysql-Server with 8G of Ram. But mysql doesn't use this ram.
But we get following error:
May 14 22:56:11 sql mysqld[5875]
On 5/15/07, Mathieu Bruneau <[EMAIL PROTECTED]> wrote:
Hi, yeah, apparenlty you're running into the 32 bits memory liimt. Note
thta some memory is allocated for the OS so you don't even have the full
4GB of ram you can technically adressesed.
The 64 bits os would increase this limit to 64gb++ (
On 5/15/07, Christoph Klünter <[EMAIL PROTECTED]> wrote:
I have set the sort_buffer_size to 1G but even this doesn't help.
Any hints ? Should we try a 64Bit-OS ?
setting sort_buffer_size to 1GB is not recommended. it is a thread specific
configuration parameter which means each thread will
Christoph Klünter a écrit :
> Hi List,
>
> We have a mysql-Server with 8G of Ram. But mysql doesn't use this ram.
> But we get following error:
>
> May 14 22:56:11 sql mysqld[5875]: 070514 22:56:10 [ERROR] /usr/sbin/mysqld:
> Got error 12 from storage engine
> May 14 22:56:11 sql mysqld[5875]:
a why this keeps increasing?
Thanks,
Rohit
- Original Message - From: "Lars Heidieker" <[EMAIL PROTECTED]>
To: "Rohit Peyyeti" <[EMAIL PROTECTED]>
Sent: Wednesday, February 01, 2006 4:37 PM
Subject: Re: Memory problems?
All these processes share the same
g?
Thanks,
Rohit
- Original Message -
From: "Lars Heidieker" <[EMAIL PROTECTED]>
To: "Rohit Peyyeti" <[EMAIL PROTECTED]>
Sent: Wednesday, February 01, 2006 4:37 PM
Subject: Re: Memory problems?
All these processes share the same address space (linux wa
In the last episode (Oct 05), Doug Wolfgram said:
> At 07:35 PM 10/5/2004, you wrote:
> >In the last episode (Oct 05), Doug Wolfgram said:
> >> When I run top after my server has been running for a few days,
> >> Mysql is using 60 or 70MB of memory. When I restart mysql, it goes
> >> back to 3000.
In the last episode (Oct 05), Doug Wolfgram said:
> When I run top after my server has been running for a few days, Mysql
> is using 60 or 70MB of memory. When I restart mysql, it goes back to
> 3000. Any idea where I should start to look for a problem? What
> causes this?
What are your mysql memo
On Jan 31, 2004, at 1:09 AM, Adam Goldstein wrote:
On Jan 30, 2004, at 10:25 AM, Bruce Dembecki wrote:
On Jan 28, 2004, at 12:01 PM, Bruce Dembecki wrote this wonderful
stuff:
So.. My tips for you:
1) Consider a switch to InnoDB, the performance hit was dramatic,
and it's
about SO much more
On Jan 30, 2004, at 10:25 AM, Bruce Dembecki wrote:
On Jan 28, 2004, at 12:01 PM, Bruce Dembecki wrote this wonderful
stuff:
So.. My tips for you:
1) Consider a switch to InnoDB, the performance hit was dramatic,
and it's
about SO much more than transactions (which we still don't do)!
Consider
> On Jan 28, 2004, at 12:01 PM, Bruce Dembecki wrote this wonderful stuff:
>>
>> So.. My tips for you:
>>
>> 1) Consider a switch to InnoDB, the performance hit was dramatic, and it's
>> about SO much more than transactions (which we still don't do)!
>>
> Consider it switched! as soon as I find
On Jan 28, 2004, at 12:01 PM, Bruce Dembecki wrote this wonderful stuff:
I don't think there would be any benefit to using InnoDB, at least not
from a transaction point of view
For the longest time I was reading the books and listening to the
experts
and all I was hearing is InnoDB is great becau
Raid 5 is just as common as any other raid in software, and on my other
boxes it does not present any problem at all... I have seen excellent
tests with raid5 in software, and many contest that software raid 5 on
a high powered system is faster than hardware raid 5 using the same
disks-- I hav
On 1/28/04 10:29 AM, wrote:
>
>So should we always use InnoDB over BerkeleyBD? I was
>under the impression Berkeley was faster and better at
>handling transactions.
>
>Dan
>
Eermm... That's outside my scope of expertise, my experiences have been
exclusively with InnoDB and before that MyISAM, an
So should we always use InnoDB over BerkeleyBD? I was
under the impression Berkeley was faster and better at
handling transactions.
Dan
-Original Message-
From: Bruce Dembecki [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 28, 2004 11:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Memory
> I don't think there would be any benefit to using InnoDB, at least not
> from a transaction point of view
For the longest time I was reading the books and listening to the experts
and all I was hearing is InnoDB is great because it handles transactions.
Having little interest in transactions per
I have had linux on soft-raid5 (6x18G, 8x9G, 4x18G) systems, and the
load was even higher... The explanation for this could be that at high
IO rates the data is not 100% synced across the spindles, and therefore
smaller files (ie files smaller than the chunk size on each physical
disk) must wai
I have managed to get what looks like >2G for the process, but, it does
not want to do a key_buffer of that size
I gave it a Key_buffer of 768M and a query cache of 1024M, and it seems
happier.. though, not noticeably faster.
[mysqld]
key_buffer = 768M
max_allowed_packet = 8M
table_cach
I don't think there would be any benefit to using InnoDB, at least not
from a transaction support view.
After your nightly optimize/repair are you also doing a flush? That may
help.
I haven't seen any direct comparisons between HFS+ and file systems
supported by Linux. I would believe that Lin
I have added these settings to my newer my.cnf, including replacing the
key_buffer=1600M with this 768M... It was a touch late today to see if
it has a big effect during the heavy load period (~3am to 4pm EST, site
has mostly european users)
I did not have any of these settings explicitly set i
The primary server (Dual Athlon) has several U160 scsi disks, 10K and
15K rpm... Approximately half the full size images are on one 73G U160,
the other half on another (about 120G of large images alone being
stored... I am trying to get him to abandon/archive old/unused images).
The system/lo
Have you tried reworking your queries a bit? I try to avoid using "IN"
as much as possible. What does EXPLAIN say about how the long queries
are executed? If I have to match something against a lot of values, I
select the values into a HEAP table and then do a join. Especially if
YOU are going
Yes, I saw this port before... I am not sure why I cannot allocate more
ram on this box- It is a clean 10.3 install, with 10.3.2 update. I got
this box as I love OSX, and have always loved apple, but, this is not
working out great. Much less powerful (and less expensive) units can do
a better
2GB was the per-process memory limit in Mac OS X 10.2 and earlier. 10.3
increased this to 4GB per-process. I've gotten MySQL running with 3GB
of RAM on the G5 previously.
This is an excerpt from a prior email to the list from back in October
when I was first testing MySQL on the G5:
> query_ca
Yes, MySQL is capable of using more than 2GB, but it still must obey
the limits of the underlying OS. This means file sizes, memory
allocation and whatever else. Have you heard of anybody allocating more
the 2GB using OSX? I've heard of quite a bit more using Linux or other
Unix flavors, but no
Others on this list have claimed to be able to set over 3G, and my
failure is with even less than 2G (though, I am unsure if there is a
combination of other memory settings working together to create an >2GB
situation combined)
Even at 1.6G, which seems to work (though, -not- why we got 4G of
You may be hitting an OSX limit. While you can install more than 2GB on
a system, I don't think any one process is allowed to allocated more
than 2GB of RAM to itself. It's not a 64-bit OS yet. You should be able
to search the Apple website for this limit.
On Jan 26, 2004, at 6:10 AM, Adam Gold
> -Original Message-
> From: Nemholt, Jesper Frank
> Sent: viernes, 09 de marzo de 2001 19:52
> To: '[EMAIL PROTECTED]'
> Subject: Memory problems/bug ?
>
>
> Hej!
>
> Using MySQL 3.22.32 on Tru64 4.0F patchkit 4. Compiled with Compaq CC.
>
> Ran optimize on a table, and after 10 minu
29 matches
Mail list logo
