Re: CPU Scalability / Scaling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Aug 14, 2020, 10:53 AM David Boreham <david@xxxxxxxxxxxxxxx> wrote:

On 8/14/2020 9:04 AM, Ben Spencer wrote:
> After a little investigation I didn't find any recent information on
> how well / linearly 389 scales from a CPU perspective. I also realize
> this is a more complicated topic with many factors which actually play
> into it.
>
> Throwing the basic question out there: Does 389 scale fairly
> linearly as the number of CPUs are increased? Is there a point where
> it drops off?

Cached reads (cached anywhere : filesystem cache, db page pool, entry
cache) should scale quite well, at least to 4/6/8 CPU. I'm not sure
about today's 8+ CPU systems but would assume probably not great scaling
beyond 8 until proven otherwise.

Interesting since we are currently sitting with 10 CPU per server. Things organically grew over time without much thought given.

Writes are going to be heavily serialized, assume no CPU scaling. Fast
I/O is what you need for write throughput.
> Where am I going with this?
> We are faced with either adding more CPUs to the existing servers or
> adding more instances or a combination of the two. The current servers
> have 10 CPU with the entire database fitting in RAM but, there is a
> regular flow of writes. Sometimes somewhat heavy thanks to batch
> updates. Gut feeling tells me to have more servers than a few huge
> servers largely because of the writes/updates and lock contention.
> Needing to balance the server sprawl as well.

I'd look at whether I/O throughput (Write IOPS particularly) can be
upgraded as a first step. Then perhaps look at system design to see if
the batch updates can be throttled/trickled to reduce the cross-traffic
interference. Usually the write load is the limiting factor scaling
because it has to be replayed on every server regardless of its read
workload.

Something to consider. Hard to resolve in the environment where the servers are.

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux