On 5/13/09 11:52 PM, "Greg Smith" <gsmith@xxxxxxxxxxxxx> wrote: > On Wed, 13 May 2009, Scott Carey wrote: > >> Can you do a quick and dirty memory bandwidth test? (assuming linux) >> >> /sbin/hdparm -T /dev/sd<device> >> >> ...its not a very accurate measurement, but its quick and highlights >> relative hardware differences very easily. > > I've found "hdparm -T" to be useful for comparing the relative memory > bandwidth of a given system as I change its RAM configuration around, but > that's about it. I've seen that result change by a factor of 2X just by > changing kernel version on the same hardware. The data volume transferred > doesn't seem to be nearly enough to extract the true RAM speed from > (guessing the cause here) things like whether the test/kernel code fits > into the CPU cache. That's too bad -- I have been using it to compare machines as well, but they are all on the same Linux version / distro. Regardless -- the results indicate a 2x to 3x bandwidth improvement... Which sounds about right if the older CPU isn't on the newer FBDIMM chipset. If both of those machines are on the same Kernel, the relative values should be a somewhat valid (though -- definitely not all that accurate). > > I'm using this nowadays: > > sysbench --test=memory --memory-oper=write --memory-block-size=1024MB > --memory-total-size=1024MB run > Unfortunately, sysbench isn't installed by default on many (most?) distros, or even available as a package on many. So its a bigger 'ask' to get results from it. Certainly a significantly better overall tool. > The sysbench read test looks similarly borked by caching effects when I've > tried it, but if you write that much it seems to give useful results. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
