Some of the hash files are getting bigger than 2 GB and we are having to design workarounds to overcome this.
Planning on biting the bullet - setting the 64BIT_FILES to 1 in the uvconfig file.
Has anybody done this?
Have you seen any degradation in the performance?
Any Red Flags?
Please share your thoughts
Changing 64BIT_FILES to 1
Moderators: chulett, rschirm, roy
Changing 64BIT_FILES to 1
Narasimha Kade
Finding answers is simple, all you need to do is come up with the correct questions.
Finding answers is simple, all you need to do is come up with the correct questions.
Make sure you understand exactly what it is you are turning on before you flip that switch, my friend. An exact search for 64BIT_FILES should turn up all of the relevant conversations on the topic.
I personally would suggest handling these beefy hashed files on an individual basis, converting just those that really need it... unless the vast majority of them need it and then we should be having a different conversation, me thinks. Out of curiousity, what kind of "workarounds" are you using at this time?
I personally would suggest handling these beefy hashed files on an individual basis, converting just those that really need it... unless the vast majority of them need it and then we should be having a different conversation, me thinks. Out of curiousity, what kind of "workarounds" are you using at this time?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Greetings Craig. :D
I am aware of the implications of switching this value. - "ALL" the new hashed files will be created as a 64 bit.
I have read conversations saying - Don't do that... it will degrade the performance ..... (But nothing quantifiable)
But have not seen anybody going this route. Wanted to check if anybody got burnt doing this.
I have advised people in the past to not do it too. But want to get the real facts.
Workaround currently using is to break up into multiple hashed files based on subset of business rules.
I am aware of the implications of switching this value. - "ALL" the new hashed files will be created as a 64 bit.
I have read conversations saying - Don't do that... it will degrade the performance ..... (But nothing quantifiable)
But have not seen anybody going this route. Wanted to check if anybody got burnt doing this.
I have advised people in the past to not do it too. But want to get the real facts.
Workaround currently using is to break up into multiple hashed files based on subset of business rules.
Narasimha Kade
Finding answers is simple, all you need to do is come up with the correct questions.
Finding answers is simple, all you need to do is come up with the correct questions.
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Leave 64BIT_FILES set to 0. The "bittage" setting in hashed files affects only the internal pointers in the hashed files - there is no interaction with the operating system.
Many hashed files require only to be small, and contain small records. With 32-bit pointers the storage overhead is 12 bytes per record; with 64-bit pointers the storage overhead doubles to 24 bytes per record.
If you need a hashed file larger than 2GiB create that one with 64-bit addressing. The only thing the larger pointers allow is to address locations in the file more than 2**31-1 bytes from the beginning of the file.
Many hashed files require only to be small, and contain small records. With 32-bit pointers the storage overhead is 12 bytes per record; with 64-bit pointers the storage overhead doubles to 24 bytes per record.
If you need a hashed file larger than 2GiB create that one with 64-bit addressing. The only thing the larger pointers allow is to address locations in the file more than 2**31-1 bytes from the beginning of the file.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Test Results:
On a Sandbox Server, I swapped the value of the 64BIT_FILES to 1 for test purpose.
As anticipated some of the files grew larger than 2 GB. (Job building them did not choke). The performance did not take a hit either.
Pardon my ignorance on the 32 Vs 64 Bit Hashed File Architecture.
Other than space [ Because the files gets bigger then 2 GB (As anticipated) ]
I am not seeing any undesirable results ... yet...
On a Sandbox Server, I swapped the value of the 64BIT_FILES to 1 for test purpose.
As anticipated some of the files grew larger than 2 GB. (Job building them did not choke). The performance did not take a hit either.
Pardon my ignorance on the 32 Vs 64 Bit Hashed File Architecture.
Other than space [ Because the files gets bigger then 2 GB (As anticipated) ]
I am not seeing any undesirable results ... yet...
Narasimha Kade
Finding answers is simple, all you need to do is come up with the correct questions.
Finding answers is simple, all you need to do is come up with the correct questions.
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
You're correct - the only undesirable consequence is wasted space.
Hashed files with either "bittage" will work fine - the hashing algorithm works in exactly the same way. All else being equal, though, a 64-bit hashed file will have slightly more groups than a 32-bit, because there is less room (because of the larger pointers) for storing actual data.
Similarly there is a slightly increased risk of overflowed buffers and oversized records, for the same reason. That's where the performance degradation would be seen, but it would not be a major hit.
Hashed files with either "bittage" will work fine - the hashing algorithm works in exactly the same way. All else being equal, though, a 64-bit hashed file will have slightly more groups than a 32-bit, because there is less room (because of the larger pointers) for storing actual data.
Similarly there is a slightly increased risk of overflowed buffers and oversized records, for the same reason. That's where the performance degradation would be seen, but it would not be a major hit.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
