- 论坛徽章:
- 0
|
请教:1G内存能承受多少并发连接数
兄弟们有话好好说
希望争论的朋友从$(MYSQL)/docs/mysql.info里能得到一些启示。另外看了一下源代码,没找到对连接数的设置做最大限制,只是与max_connections比较而已
If you build MySQL yourself, you can patch LinuxThreads for
better stack use. See *Note source-notes-linux::. If you do
not want to patch LinuxThreads, you should set
`max_connections' to a value no higher than 500. It should be
even less if you have a large key buffer, large heap tables,
or some other things that make `mysqld' allocate a lot of
memory, or if you are running a 2.2 kernel with a 2GB patch.
If you are using our binary or RPM version 3.23.25 or later,
you can safely set `max_connections' at 1500, assuming no
large key buffer or heap tables with lots of data. The more
you reduce `STACK_SIZE' in LinuxThreads the more
threads you can safely create. We recommend values between
128KB and 256KB.
......
(注:MYSQL做过的benchmark)
We have tested MySQL on the 2.4 kernel on a two-CPU machine
and found MySQL scales _much_ better. There was virtually no
slowdown on query throughput all the way up to 1,000 clients,
and the MySQL scaling factor (computed as the ratio of
maximum throughput to the throughput for one client) was
180%. We have observed similar results on a four-CPU system:
Virtually no slowdown as the number of clients was increased
up to 1,000, and a 300% scaling factor. Based on these
results, for a high-load SMP server using a 2.2 kernel, we
definitely recommend upgrading to the 2.4 kernel at this
point.
We have discovered that it is essential to run the `mysqld'
process with the highest possible priority on the 2.4 kernel
to achieve maximum performance. This can be done by adding a
`renice -20 $$' command to `mysqld_safe'. In our testing on a
four-CPU machine, increasing the priority resulted in a 60%
throughput increase with 400 clients. |
|