RE: One big chunk or many smaller ones?
Neil Raw or cooked chunks? All chunks on the same physical device? Rootdbs, phys log dbs, loglog dbs on same devices? AIO or KAIO? Enough AIO threads? At checkpoints a page cleaner is assigned to each chunk, so more chunks, more active cleaners, quicker checkpoints. Personally I would have 10 dbspaces of 10 Gb, use some for data, some for index and generally spread things around. On a 380Gb database with 150 Mb log activity per 20 mins (peak times) and checkpoint between 0 and 1 second. (admittedly an IBM p550 with fastT700 storage, but some principles don't vary) Keith -> -----Original Message----- -> From: Neil Truby [mailto:neil.truby@ardenta.com] -> Sent: Thursday, July 27, 2006 1:38 PM -> To: informix-list@iiug.org -> Subject: One big chunk or many smaller ones? -> -> -> IDS 10.0 on RHEL AS 4: -> -> We're setting up a new database server for an OLTP application (24x7 -> website). We've agreed on 100Gytes of application dbspace -> in a single -> dbspace. What are poeple's opinions on having 10 x 10g -> chunkis rather than -> 1 x 100g one? -> -> On an issue that may or may not be related, we were having -> performance -> issues (still are in fact) on a similar environmment, albeit -> 10.0FC3 on -> Solaris 9, where the symptom was unexpectedly long -> checkppoints (up to 10s, -> and slow flush times as we observed them). IBM UK Tech -> Support advised us -> to split the data across multiple dbspaces to try to speed -> up checkpoint -> activity. We did this: it made no noticeable difference to -> checkpoint -> speeds but is more work to administer. -> -> I'd be interested in the theories and practial experience of others, -> particularly where we're having a single dbspace. -> -> Thanks -> -- -> Neil Truby t:01932 724027 -> Director m:07798 811708 -> Ardenta Limited e:neil.truby@ardenta.com -> -> -> _______________________________________________ -> Informix-list mailing list -> Informix-list@iiug.org -> http://www.iiug.org/mailman/listinfo/informix-list -> *********************************************************************************************** This message is sent in strict confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. ***********************************************************************************************
"Simmons, Keith" <keith.simmons@office2office.biz> wrote in message news:mailman.82.1154006909.20706.informix-list@iiug.org... >> Raw or cooked chunks? All chunks on the same physical device? Rootdbs, phys log dbs, loglog dbs on same devices? AIO or KAIO? Enough AIO threads? Not raw. Using an EMC Clariion so no assumptions can be made about that underlying physical disk. kaio. Plnety of aio threads. >> Personally I would have 10 dbspaces of 10 Gb, use some for data, some for index and generally spread things around. Unless you've preternaturally rigid control over your FastT in the background, I'd be interested to know what benfit you think you're getting from doing so. I take your point about more cleaners/more chunks though. >> On a 380Gb database with 150 Mb log activity per 20 mins (peak times) and checkpoint between 0 and 1 second. (admittedly an IBM p550 with fastT700 storage, but some principles don't vary) It would have been even quicker if you'd bought it from us you know ... ;-)