Re: Which indicator determines general freenet performance? CPU bottleneck or not?
"Wolfram Goetz" <[email protected]>
| Newsgroups | gmane.network.freenet.support |
|---|---|
| Message-ID | <trinity-034a1911-bde0-40a2-be07-1aa75f043999-1404578168285@3capp-gmx-bs56> |
> Gesendet: Samstag, 05. Juli 2014 um 18:05 Uhr > Von: "Steve Dougherty" <steve-kVTqj8yhOEv2eFz/[email protected]> > An: [email protected] > Betreff: Re: [freenet-support] Which indicator determines general freenet performance? CPU bottleneck or not? > > On 07/05/2014 08:10 AM, Wolfram Goetz wrote: > > Hello, > > > > which indicator is more important for the overall performance of Freenet: > > The input/output rates or the access rates? Or is it something else? > > > > I'm asking because I'm currenty running a dedicated Freenet machine on > > Kubuntu 14.04 and I wonder if I still have a CPU bottleneck. Hardware is a > > Celeron G1620 (Ivy Bridge, 2x 2.7 GHz), 4TB 3,5'' 5900rpm HDD, had upgraded > > from a much slower AMD E-350 (2x 1,6 GHz, less IPC). > > > > The system info says the CPU is rarely above 50% load. But I get slower > > input/output rates than on a faster machine (i5-2500k @ 4x 4.0 GHz, Windows > > 7, system on a SSD, Freenet on a 7.200rpm HDD) with a test install of > > freenet. It's roughly 150KiB/s vs. 300 KiB/s. Access rates do not differ > > that much: About 15/s vs. 17/s. > > Hm, I'm not sure. I'm not aware of many people profiling Freenet. > > The thing that stands out to me is the machine getting less throughput > has a slower (5900 RPM vs 7200 RPM) hard drive. > > Are the datastores the same size? Are success rates different? Datastore sizes are different: 3,2 TiB (320 GiB occupied) on the slower machine, 500 GiB (60 GiB occupied) on the faster one. Success rates are much different throughout, ranging from 31% vs. 0.1% in favor of the faster machine (client cache CHK) to 1.2% vs. 4.8% (store CHK) with the slower machine ahead in this case. Can't see a pattern. But please don't waste too much time on this, I just thought there might be a simple answer. I will search for a Linux tool to check the I/O queue depths of the slower harddisk and report back if that seems to be the cause. Best regards, Wolfram _______________________________________________ Support mailing list [email protected] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-request-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ@public.gmane.org?subject=unsubscribe