I dind't want to pull you into that Arnaud, I was just interested in the performance test results, that's all. I hope it's gets worked out and the performance improves, good luck.
On Thu, Apr 12, 2018 at 5:15 PM, PAC Brion Arnaud < arnaud.br...@panalpina.com> wrote: > Stefan, > > I do not want to enter the details of a 6 months lasting story, but to > summarize it, such performance tests have been successfully conducted > against our very first setup, which in between time has been subject to > countless changes (TSM version, O.S. version, endianness from Big to Little > endian, extension of the FS900 capacity, redesign of the storage pools > layout and so on), the whole under huge time pressure, having the result > that the current setup could not be benchmarked anymore, as it was already > productive ... > > Cheers. > > Arnaud > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Stefan Folkerts > Sent: Thursday, April 12, 2018 2:10 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: disabling compression and/or deduplication for a client > backing up against deduped/compressed directory-based storage pool > > I understand, I didn't know you were that deep into the case already, I > wouldn't presume to be able to solve this via a few emails if support is > working on it. > > What I am interested in is did you run the blueprint benchmarks? the perl > script that can benchmark your database and your containerpool volumes? > The blueprints give values that you should be getting in order to expect > blueprint performance results, this way you can quantify your performance > issue in how many IOP/s or MB/s your behind where you need to be to run the > load you need to run. > > Regards, > Stefan > > > > > On Wed, Apr 11, 2018 at 2:10 PM, PAC Brion Arnaud < > arnaud.br...@panalpina.com> wrote: > > > Dear Stefan, > > > > Thanks a lot for your very kind offer ! > > > > Without underrating the power of this list, I however doubt that we will > > able to find a solution that easily : we opened a case with IBM and > > involved EMC/Dell as well, so far without much success, even after 5 > months > > intensive monitoring and tuning attempts at all levels (Linux kernel, > > communication layer, TSM DB fixes, access mode change on Isilon etc ...) > > > > I must share as well that some of our partners voices raised when the > > decision had been made to go with Isilon storage, warning us that the > > offered solution would not be powerful enough to sustain the intended > > workload. It might very well be that they were right, and that in this > > particular case, budget considerations have ruled over pragmatism, > leading > > to that very uncomfortable situation ... > > > > To finally answer your question : both active log and database are stored > > on a Flashsytem 900 array, dedicated to TSM server only. > > > > Cheers. > > > > Arnaud > > > > ************************************************************ > > ******************************************************************** > > Backup and Recovery Systems Administrator > > Panalpina Management Ltd., Basle, Switzerland, > > CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH > > Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01 > > Direct: +41 (61) 226 19 78 > > e-mail: arnaud.br...@panalpina.com > > This electronic message transmission contains information from Panalpina > > and is confidential or privileged. > > This information is intended only for the person (s) named above. If you > > are not the intended recipient, any disclosure, copying, distribution or > > use or any other action based on the contents of this > > information is strictly prohibited. > > > > If you receive this electronic transmission in error, please notify the > > sender by e-mail, telephone or fax at the numbers listed above. Thank > you. > > ************************************************************ > > ******************************************************************** > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > > Stefan Folkerts > > Sent: Wednesday, April 11, 2018 7:43 AM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: disabling compression and/or deduplication for a client > > backing up against deduped/compressed directory-based storage pool > > > > That's no fun, maybe we can help! > > What storage are you using for your active log and database? > > > > Regards, > > Stefan > > > > On Mon, Apr 9, 2018 at 6:06 PM, PAC Brion Arnaud < > > arnaud.br...@panalpina.com > > > wrote: > > > > > Hi Stefan, > > > > > > Thanks a lot for appreciated feedback ! > > > > > > >> You can, however, disable compression on the storagepool-level. > > > > > > This is unfortunately what I intended to avoid : if I disable it, then > > > lots of clients will be impacted, and the server's performance will for > > > sure improve ... > > > > > > >> Are you using an IBM blueprint configuration for the Spectrum > Protect > > > > > > I wish I could : my life would have been much easier ! Unfortunately > > > management took the (definitively bad) decision to invest in a EMC/Dell > > > Isilon array to be our Spectrum Scale server storage. > > > I'm now fighting since 6 months to have the whole working together, so > > far > > > without real success : performance is horrible :-( > > > > > > Cheers. > > > > > > Arnaud > > > > > > > > > -----Original Message----- > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of > > > Stefan Folkerts > > > Sent: Thursday, April 05, 2018 5:48 PM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: Re: disabling compression and/or deduplication for a client > > > backing up against deduped/compressed directory-based storage pool > > > > > > Hi, > > > > > > With the directory containerpool you cannot, for as far as I know, > > disable > > > an attempt to deduplicate the data and if the data is able to > deduplicate > > > it will be deduplicated. > > > You can, however, disable compression on the storagepool-level. If you > > > disable it on the containerpool client-side settings for deduplication > > will > > > have no effect on compression within the pool. > > > > > > Are you using an IBM blueprint configuration for the Spectrum Protect > > > environment? > > > > > > Regards, > > > Stefan > > > > > > > > > On Tue, Apr 3, 2018 at 6:06 PM, PAC Brion Arnaud < > > > arnaud.br...@panalpina.com > > > > wrote: > > > > > > > Hi All, > > > > > > > > Following to global client backup performance issues on some new TSM > > > > server, which I suspect to be related to the workload induced on TSM > > > > instance by deduplication/compression operations, I would like to do > > some > > > > testing with a client, selectively disabling compression or > > > deduplication, > > > > possibly both of them on it. > > > > > > > > However, the TSM server has been configured to only make use of > > > > directory-based storage pools, which have been defined having > > > deduplication > > > > and compression enabled. > > > > > > > > Thus my question : is there any mean to configure a client, so that > its > > > > data will not be compressed or deduplicated ? > > > > > > > > From my understanding, setting up "compression no" in the client > option > > > > file will be of no use, as the server will still be compressing the > > data > > > at > > > > storage pool level. > > > > Likewise, setting up "deduplication no" in the client option file > will > > > > refrain the client to proceed to deduplication, but the server still > > > will. > > > > The last remaining possibility that I can think of, to disable > > > > deduplication, would be to make use of some "exclude.dedup" statement > > on > > > > client side, that would exclude anything subject to backup. > > > > > > > > What are your thoughts ? Am I condemned to define new storage pools > not > > > > enabled for deduplication and or compression to do such testing, or > is > > > > there some other mean ? > > > > > > > > Thanks a lot for appreciated feedback ! > > > > > > > > Cheers. > > > > > > > > Arnaud > > > > > > > > ************************************************************ > > > > ******************************************************************** > > > > Backup and Recovery Systems Administrator > > > > Panalpina Management Ltd., Basle, Switzerland, > > > > CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH > > > > Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01 > > > > Direct: +41 (61) 226 19 78 > > > > e-mail: arnaud.br...@panalpina.com<mailto:arnaud.br...@panalpina.com > > > > > > This electronic message transmission contains information from > > Panalpina > > > > and is confidential or privileged. > > > > This information is intended only for the person (s) named above. If > > you > > > > are not the intended recipient, any disclosure, copying, distribution > > or > > > > use or any other action based on the contents of this > > > > information is strictly prohibited. > > > > > > > > If you receive this electronic transmission in error, please notify > the > > > > sender by e-mail, telephone or fax at the numbers listed above. Thank > > > you. > > > > ************************************************************ > > > > ******************************************************************** > > > > > > > > > >