Zoltan
SO sorry, my original TSM reference was a hair stale -- try this one:
https://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.1/com.ibm.itsm.perf.doc/t_perf_diskos_lnx.html
I understand you have constraints, so I am not telling you to do something
you cannot do.
What I am saying is - you derive more performance benefits with more
controllers and spindles - whatever you can do to increase those, will
improve your performance (up to a point - you can surpass your
motherboard's ability to push traffic through disk controllers but I don't
think this is your problem).
If you can split your database to 2 filesystems that are on 2 separate
controllers, then you have increased the parallelization of disk I/O
processing for your database. Even a pair of mirrors on the same array
controller would be an improvement over a single mirror on an array
controller.
Out of curiousity - if your files are all going to tape anyway, what was
the purpose for so many TB of disk pool? Can you sacrifice some diskpool
in order to improve DB/log performance? You may be better off with a pair
of mirrors for your DB, another mirror for logs, another mirror for
archivelogs, then you can consume the rest of your slots for hotspares
and/or disk pool.
If you can't speed up your DB/log processing, don't even think about
deduplication, you will spend a LOT of time waiting for the log files to be
reconciled against the DB.
Best regards,
Mike, x7942
RMD IT Client Services
On Tue, Feb 2, 2016 at 7:38 AM, Zoltan Forray <zforray AT vcu DOT edu> wrote:
> I understand and we have been using ext4 since it was available. All of my
> stgpools are ext4. The DB filesystem is ext3 per the requirements in the
> document you referenced for setting up TSM on Linux.
>
> However, they are spread across 2-ext4 filesystems due to the 16TB limit
> for ext4.
>
> Are you saying I should create multiple ext4 filesystems (i.e. 2TB chunks)
> vs the 2-big ones I am currently using? I can't split up the RAID5 array
> due to loosing too much storage.
>
> On Mon, Feb 1, 2016 at 2:05 PM, Ryder, Michael S <
> michael_s.ryder AT roche DOT com>
> wrote:
>
> > Hello Zoltan:
> >
> > I have about 500 volumes spread across a dozen or so EXT4 filesystems,
> and
> > get performance that operates at the maximum throughput of the hardware.
> >
> > Here is a good primer on the differences. The bottom line - ext4 can
> > perform better than ext3.
> >
> > http://www.thegeekstuff.com/2011/05/ext2-ext3-ext4/
> >
> > Best regards,
> >
> > Mike, x7942
> > RMD IT Client Services
> >
> > On Thu, Jan 28, 2016 at 1:43 PM, Zoltan Forray <zforray AT vcu DOT edu>
> > wrote:
> >
> > > Mike,
> > >
> > > Thanks, again. Very helpful. So, did I understand your earlier
> > > statement/comment that you disagree with "*Set the LVM read-ahead to 0
> > for
> > > all logical volumes on disk systems that provide adaptive read-ahead
> > > capabilities, for example, enterprise-type disk systems.*"
> > >
> > > I also read the statement "*For the Tivoli Storage Manager database and
> > > logs, use the ext3 file system.*" Whats up with that? They explain
> why
> > > you should use ext4 for the storage volumes but no details on ext3 for
> > > DB/logs?
> > >
> > > On Thu, Jan 28, 2016 at 1:05 PM, Ryder, Michael S <
> > > michael_s.ryder AT roche DOT com
> > > > wrote:
> > >
> > > > Hi Zoltan
> > > >
> > > > Here is the reference... I know it is for TSM 7.1, but the reference
> is
> > > > specific to RHEL and it's filesystems, which is still relevant to the
> > > > discussion, I think:
> > > >
> > > >
> > > >
> > >
> >
> http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.perf.doc/t_perf_diskos_lnx.html
> > > >
> > > > Best regards,
> > > >
> > > > Mike, x7942
> > > > RMD IT Client Services
> > > >
> > > > On Thu, Jan 28, 2016 at 11:38 AM, Zoltan Forray <zforray AT vcu DOT edu>
> > wrote:
> > > >
> > > > > On Wed, Jan 27, 2016 at 10:05 AM, Ryder, Michael S <
> > > > > michael_s.ryder AT roche DOT com> wrote:
> > > > >
> > > > > > Did you follow the docs and disable RHEL's read-ahead
> > > > > > caching? If so, you may want to consider enabling it.
> > > > > >
> > > > >
> > > > > Mike,
> > > > >
> > > > > Can you expand on your statement about RHEL read-ahead cache and
> some
> > > > > tuning/config document you refer to? We were unaware of such a
> > > document
> > > > > (or config value). The RHEL read-ahead cache is set to the default
> > of
> > > > > 128K. Currently all caching is via PERC.
> > > > >
> > > > >
> > > > > --
> > > > > *Zoltan Forray*
> > > > > TSM Software & Hardware Administrator
> > > > > Xymon Monitor Administrator
> > > > > Virginia Commonwealth University
> > > > > UCC/Office of Technology Services
> > > > > www.ucc.vcu.edu
> > > > > zforray AT vcu DOT edu - 804-828-4807
> > > > > Don't be a phishing victim - VCU and other reputable organizations
> > will
> > > > > never use email to request that you reply with your password,
> social
> > > > > security number or confidential personal information. For more
> > details
> > > > > visit http://infosecurity.vcu.edu/phishing.html
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *Zoltan Forray*
> > > TSM Software & Hardware Administrator
> > > Xymon Monitor Administrator
> > > Virginia Commonwealth University
> > > UCC/Office of Technology Services
> > > www.ucc.vcu.edu
> > > zforray AT vcu DOT edu - 804-828-4807
> > > Don't be a phishing victim - VCU and other reputable organizations will
> > > never use email to request that you reply with your password, social
> > > security number or confidential personal information. For more details
> > > visit http://infosecurity.vcu.edu/phishing.html
> > >
> >
>
>
>
> --
> *Zoltan Forray*
> TSM Software & Hardware Administrator
> Xymon Monitor Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> www.ucc.vcu.edu
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit http://infosecurity.vcu.edu/phishing.html
>
|
