Hi,
2005-02-02 kl. 20.23 skrev Jim Hoadley:
> Mikael et al. --
>
>> Actually in multi-CPU boxes it can be very
>> beneficial to lock the ndbd process to a CPU (advantegous also from
>> use of
>> cache memory and gives very predictable performance) if the OS
>> supports
>> such actions.
>
> This brings to mind 2 general questions.
>
> 1) If I am putting together a 3-node cluster (API and NDB on BOX1, API
> and NDB
> on BOX2, MGM on BOX3), how much will it help to buy 2-CPU boxes
> instead of
> single CPUs? Worth the added price? These would be something like
> 3.6GHz Xeon,
> 4GB RAM and 2 36GB 10k RPM SCSI drives.
>
For BOX1 and BOX2 it would certainly help, I can't really see any
reasons why it couldn't more or less double
the workload you can handle as long as the disks can handle it which I
presume they would in this case. For
BOX3 you don't need any second CPU and even the CPU itself could be a
low-end variant.
> 2) If so, what kind of performance gain, if any, would I get from
> locking the
> NDBD process to one of the CPUs?
>
In this case it would mostly provide better and more predictable
latency on individual queries whereas overall
throughput would likely go down since the mysqld process usually
consumes more CPU power than the ndbd
process.
Rgrds Mikael
> Thanks in advance!
>
> -- Jim Hoadley
>
>
> --- Mikael Ronström <mikael@stripped> wrote:
>
>> Hi,
>>
>> 2005-02-02 kl. 01.58 skrev Mike Schroeder:
>>
>>> I have similar questions:
>>>
>>> So if we use dual 64-bit AMD Opterons with 16 GB RAM, will MySQL
>>> access all 16 GB?
>>> Has anyone found any point of diminishing returns on the amount of
>>> memory in a server?
>>> Which is better: fewer servers with more memory, or more servers with
>>> less memory?
>>>
>>
>> If the OS is 64-bit the answer is yes, both for the MySQL Server and
>> for the ndbd processes
>> in the MySQL Cluster. For a 32 bit OS, the limitation on OS exists as
>> Marco W. pointed out
>> below. For ndbd processes Marco W. notes were correct that you can run
>> several ndbd processes
>> per box to make use of a memory bigger than 4 GB (my experience is
>> that
>> the limit is even 3 GB or
>> less since the OS uses up some of the virtual memory addresses plus
>> due
>> to fragmentation of
>> virtual memory address space).
>>
>> Whether to use fewer servers or more servers is more dependent on the
>> number of CPU's. One ndbd
>> can make use of between 1-2 CPU's so if you have a 4-CPU box you need
>> at least two ndbd or one
>> ndbd + mysqld to fully utilise the CPU's. It is also a matter of
>> whether best throughput or lowest latency
>> is desired. Best throughput is achieved if you allocate around 1 CPU
>> per ndbd node and best latency
>> if you have 1.5-2 CPU's allocated to the ndbd process. Actually in
>> multi-CPU boxes it can be very
>> beneficial to lock the ndbd process to a CPU (advantegous also from
>> use
>> of cache memory and gives
>> very predictable performance) if the OS supports such actions.
>>
>> Rgrds Mikael
>>
>>>
>>>
>>>
>>>
>>> Marco Wertejuk wrote:
>>>
>>>> Hey,
>>>>
>>>> | What is the limitation of a 32-bit architecture as it
>>>> | relates to RAM and MySQL Cluster?
>>>>
>>>> I actually don't know about how mysql cluster is programmed
>>>> according to memory usage, but I can tell you that no
>>>> application can use more than 4GB memory on 32bit x86
>>>> servers. Redhat enterprise supports more that 4GB using
>>>> high address memory and em64t technology, but due to
>>>> how memory configurations above the 32bit address limitations
>>>> are supported no application can use more than 4GB.
>>>>
>>>> Of course you can run 2 4GB memory consuming applications
>>>> on you 8GB server but this might not work with mysql cluster.
>>>>
>>>> You should probably consider using a 4 node cluster where
>>>> you have 2 groups with each 2 nodes for redundancy and splitting the
>>>> dataset across two servers.
>>>>
>>>> I think this will be easier for you at the cost of
>>>> more hardware and probably more point of failures.
>>>>
>>>>
>>>
>>> --
>>> MySQL Cluster Mailing List
>>> For list archives: http://lists.mysql.com/cluster
>>> To unsubscribe:
>>> http://lists.mysql.com/cluster?unsub=1
>>>
>>>
>> Mikael Ronström, Senior Software Architect
>> MySQL AB, www.mysql.com
>>
>> Jumpstart your cluster:
>> http://www.mysql.com/consulting/packaged/cluster.html
>>
>>
>> --
>> MySQL Cluster Mailing List
>> For list archives: http://lists.mysql.com/cluster
>> To unsubscribe:
>> http://lists.mysql.com/cluster?unsub=1
>>
>>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Find what you need with new enhanced search.
> http://info.mail.yahoo.com/mail_250
>
> --
> MySQL Cluster Mailing List
> For list archives: http://lists.mysql.com/cluster
> To unsubscribe:
> http://lists.mysql.com/cluster?unsub=1
>
Mikael Ronström, Senior Software Architect
MySQL AB, www.mysql.com
Jumpstart your cluster:
http://www.mysql.com/consulting/packaged/cluster.html
