Re: TSM 6 database space performance question
While they are getting the advantage of the disk subsystem spreading the lun over many drives, they are not getting an advantage at the OS level of balanced I/O between the luns unless they are using some kind of OS level stripping. I'm not really familiar with Linux . . . are they using LVM and spreading the physical partitions across both luns, or, some kind of true striping across the luns? A lun is not just capacity, but also X amount of iops. If the 2 luns are simply concatinated then the iops of the new lun is going to be way under utilizied until the db grows into the space, and even then it will probably be unbalanced. This is also true for the disks in the storage system - the drives represent capacity (mb) as well as iops. A disk iin the array not carrying it's share of the i/o load is being wasted. Rick John D. Schneider john.schnei...@c To OMPUTERCOACHINGCO ADSM-L@VM.MARIST.EDU MMUNITY.COM cc Sent by: ADSM: Dist Stor Subject Manager TSM 6 database space performance ads...@vm.marist question .EDU 05/11/2010 04:21 PM Please respond to ADSM: Dist Stor Manager ads...@vm.marist .EDU Greetings, I have a customer running TSM 6.1.3 on a Linux RedHat 5.4 server. They are using high-performance SAN attached disk for the TSM database and logs. They have created the TSM database all in one directory under one filesystem. Recently then needed to add more space, and they carved out a lun from another RAID group, and then added that lun to the existing filesystem. TSM shows that it now has the additional space, but it is still all under one directory. In reading the Performance Guide and Admin Guide, they both recommend spreading the data out over multiple directories, putting each directory behind separate disks/luns. This certainly makes sense to spread the I/O out over multiple luns, and I get that. But is there anything wrong with the way my customer has done it? They are using multiple luns from different RAID groups, but they are all put together behind one directory. Is this going to become a problem as they add more and more load to this instance? If TSM has lots of separate directories and they are across multiple luns, does TSM do it's database I/O differently? Best Regards, John D. Schneider The Computer Coaching Community, LLC Cell: (314) 750-8721 - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
TSM 6 database space performance question
Greetings, I have a customer running TSM 6.1.3 on a Linux RedHat 5.4 server. They are using high-performance SAN attached disk for the TSM database and logs. They have created the TSM database all in one directory under one filesystem. Recently then needed to add more space, and they carved out a lun from another RAID group, and then added that lun to the existing filesystem. TSM shows that it now has the additional space, but it is still all under one directory. In reading the Performance Guide and Admin Guide, they both recommend spreading the data out over multiple directories, putting each directory behind separate disks/luns. This certainly makes sense to spread the I/O out over multiple luns, and I get that. But is there anything wrong with the way my customer has done it? They are using multiple luns from different RAID groups, but they are all put together behind one directory. Is this going to become a problem as they add more and more load to this instance? If TSM has lots of separate directories and they are across multiple luns, does TSM do it's database I/O differently? Best Regards, John D. Schneider The Computer Coaching Community, LLC Cell: (314) 750-8721
Re: TSM 6 database space performance question
It would probably not be a problem with it working, but with the two lun's concatenated, there is probably little to no chance DB2 will be able spread the I/O out among the 2 lun's. If it's in a separate filesystem, DB2 will spread the data out across them. It will be even worse with 3, 4, 5, or more lun's. On Tue, May 11, 2010 at 3:21 PM, John D. Schneider john.schnei...@computercoachingcommunity.com wrote: Greetings, I have a customer running TSM 6.1.3 on a Linux RedHat 5.4 server. They are using high-performance SAN attached disk for the TSM database and logs. They have created the TSM database all in one directory under one filesystem. Recently then needed to add more space, and they carved out a lun from another RAID group, and then added that lun to the existing filesystem. TSM shows that it now has the additional space, but it is still all under one directory. In reading the Performance Guide and Admin Guide, they both recommend spreading the data out over multiple directories, putting each directory behind separate disks/luns. This certainly makes sense to spread the I/O out over multiple luns, and I get that. But is there anything wrong with the way my customer has done it? They are using multiple luns from different RAID groups, but they are all put together behind one directory. Is this going to become a problem as they add more and more load to this instance? If TSM has lots of separate directories and they are across multiple luns, does TSM do it's database I/O differently? Best Regards, John D. Schneider The Computer Coaching Community, LLC Cell: (314) 750-8721 -- Andy Carlson --- Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month, The feeling of seeing the red box with the item you want in it:Priceless.
Re: TSM 6 database space performance question
Hi John, We are running TSM 6.1.3.3 on AIX 6.1 and we already increased TSM DB2 Database space twice using the same Filesystem (directory). TSM documentation only mention the use of a new filesystem to increase the size of the DB using EXTEND DBSPACE new_filesystem . I don't think extending TSM DB across 2-3-4 filesystem would spread the I/O more then using only one filesystem based on the fact that it is the number of disk your DB is spread across that will make the difference. Your LUNs need to be spread across different raid groups in order to provide the best performance. I really think one directory can be as efficient as 2 or 3. Pierre Billaudeau Analyste en stockage Livraison des Infrastructures Serveurs Société des Alcools du Québec 514-254-6000 x 6559 -Message d'origine- De : ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] De la part de John D. Schneider Envoyé : 11 mai 2010 16:21 À : ADSM-L@VM.MARIST.EDU Objet : [ADSM-L] TSM 6 database space performance question Greetings, I have a customer running TSM 6.1.3 on a Linux RedHat 5.4 server. They are using high-performance SAN attached disk for the TSM database and logs. They have created the TSM database all in one directory under one filesystem. Recently then needed to add more space, and they carved out a lun from another RAID group, and then added that lun to the existing filesystem. TSM shows that it now has the additional space, but it is still all under one directory. In reading the Performance Guide and Admin Guide, they both recommend spreading the data out over multiple directories, putting each directory behind separate disks/luns. This certainly makes sense to spread the I/O out over multiple luns, and I get that. But is there anything wrong with the way my customer has done it? They are using multiple luns from different RAID groups, but they are all put together behind one directory. Is this going to become a problem as they add more and more load to this instance? If TSM has lots of separate directories and they are across multiple luns, does TSM do it's database I/O differently? Best Regards, John D. Schneider The Computer Coaching Community, LLC Cell: (314) 750-8721 ___ Information confidentielle: Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci.
Re: TSM 6 database space performance question
Ours is designed the same, I asked the same questions and was given the following advice: The alternative to specifying multiple database directories is to use hardware RAID controller or LVM to assemble multiple disks into a single filespace/directory, You don't get the benefit of DB2's stripping when you do this, but what you loose is often made up for by the hardware's stripping. The other consideration is when doing this is that DB2 would normally throttle its I/Os going to the single directory (on the assumption that it represents a single disk), but there's a DB2 tuning parameter you can use to tell DB2 that the directory is backed by multiple disks, and to schedule its I/O accordingly. In fact, TSM sets this parameter by default, so out of the box, DB2 will assume its database directories are backed by multiple disks Rod -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Andrew Carlson Sent: Tuesday, May 11, 2010 3:45 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 6 database space performance question It would probably not be a problem with it working, but with the two lun's concatenated, there is probably little to no chance DB2 will be able spread the I/O out among the 2 lun's. If it's in a separate filesystem, DB2 will spread the data out across them. It will be even worse with 3, 4, 5, or more lun's. On Tue, May 11, 2010 at 3:21 PM, John D. Schneider john.schnei...@computercoachingcommunity.com wrote: Greetings, I have a customer running TSM 6.1.3 on a Linux RedHat 5.4 server. They are using high-performance SAN attached disk for the TSM database and logs. They have created the TSM database all in one directory under one filesystem. Recently then needed to add more space, and they carved out a lun from another RAID group, and then added that lun to the existing filesystem. TSM shows that it now has the additional space, but it is still all under one directory. In reading the Performance Guide and Admin Guide, they both recommend spreading the data out over multiple directories, putting each directory behind separate disks/luns. This certainly makes sense to spread the I/O out over multiple luns, and I get that. But is there anything wrong with the way my customer has done it? They are using multiple luns from different RAID groups, but they are all put together behind one directory. Is this going to become a problem as they add more and more load to this instance? If TSM has lots of separate directories and they are across multiple luns, does TSM do it's database I/O differently? Best Regards, John D. Schneider The Computer Coaching Community, LLC Cell: (314) 750-8721 -- Andy Carlson --- Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month, The feeling of seeing the red box with the item you want in it:Priceless. This email and any files transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended addressee, then you have received this email in error and any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Please notify us immediately of your unintended receipt by reply and then delete this email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates will not be held liable to any person resulting from the unintended or unauthorized use of any information contained in this email or as a result of any additions or deletions of information originally contained in this email.
