On Wed, 9 Dec 2009 23:07:02 +0100 Michiel van Baak <mich...@vanbaak.info> wrote:
> On 22:56, Wed 09 Dec 09, Robert wrote: > > Just last month i have seen a database server being upgraded from > > 32GB to 256GB of RAM because that was easier (to justify) for them > > than to fix their horrible db layout. > > That must have been sourceforge.net ;) > No, seriously, you must be kidding here. > That is seriously fucked up. Way offtopic, whatever. :) No, not sf.net. Yes, i wish i would have been called in earlier. At the end of the year i have no idea what that financial crisis they have been talking was about. For them a case of too much money left on the budget after massiv layoffs, i guess. (And they are not the only case.) SSD for ARC and ZIL would have been a better investment together with a simple db split. Too many blobs trashing the cache and no single view defined. Inhouse development has it's advantages... Let's not talk about the software accessing the db, new query = new connection... Only got called in after the fact to check if the network can manage the new improved database, ... Nobody could tell me where the OpenBSD firewalls went since i was last there... Shruged, implemented a mail notification if any of their 10Gb links hit 10% saturation and told them to get a better salse rep. Heck, i'd taken a bet that after optimization my laptop running OpenBSD (after i had put a SLC SSD in it) with atached usb2 disks would have done a better job than their old setup with 32GB. Even now they have more spindles of rotating rust than GB of RAM backing the DB. Yes, that bad. - Robert
