Re: [U2] Slow list traffic
For those who have been reporting issues receiving mail from the list recently, I believe we have corrected the issue. An automatic update broke our DNS server so that it would not respond to Reverse DNS queries. Since many of the large ISPs (including AOL, Comcast, etc) use rDNS queries to validate senders, they were rejecting mail from the list. The DNS server has been patched, and emails should be going out successfully to all subscribers now. Larry Hiscock Moderator ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow list traffic
Thank you Larry! Today I received all the emails from the past few weeks that I was missing! -Dianne On 10/1/2013 1:22 PM, Larry Hiscock wrote: For those who have been reporting issues receiving mail from the list recently, I believe we have corrected the issue. An automatic update broke our DNS server so that it would not respond to Reverse DNS queries. Since many of the large ISPs (including AOL, Comcast, etc) use rDNS queries to validate senders, they were rejecting mail from the list. The DNS server has been patched, and emails should be going out successfully to all subscribers now. Larry Hiscock Moderator ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] SLOW
Some 15 years ago I worked for a place that put together a team to speed up their UniData machines. We found Stupid Coding Practices and other things that slowed the systems to a crawl. Tim Snyder of Rocket was on that team. You can hire him through Rocket to check out your system. I'm sure it would be well worth it. Bruce M Neylon Health Care Management Group From: Drew William Henderson d.hender...@moreheadstate.edu To: U2-Users@listserver.u2ug.org U2-Users@listserver.u2ug.org Date: 10/07/2011 04:26 PM Subject:[U2] SLOW Sent by:u2-users-boun...@listserver.u2ug.org with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] SLOW
On 10/10/11 09:52, bney...@hcmg.net wrote: Some 15 years ago I worked for a place that put together a team to speed up their UniData machines. We found Stupid Coding Practices and other things that slowed the systems to a crawl. Tim Snyder of Rocket was on that team. You can hire him through Rocket to check out your system. I'm sure it would be well worth it. This is humorous. I'll assume Drew is a Datatel client. Let's just say that their code is less than optimal in many cases, particularly course registration. But like any product, anything that has millions of lines of source code and is 20+ years old (or older, in some cases) is likely to be inefficient. Likewise, rewriting it from the ground up isn't going to happen (until Datatel moves everything to MSSQL, but that's a whole different thread). From: Drew William Hendersond.hender...@moreheadstate.edu To: U2-Users@listserver.u2ug.orgU2-Users@listserver.u2ug.org Date: 10/07/2011 04:26 PM Subject:[U2] SLOW Sent by:u2-users-boun...@listserver.u2ug.org with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Butera, Ph.D. Manager of ERP Systems Hampshire College jbut...@hampshire.edu 413-559-5556 ...we must choose between what is right and what is easy... Dumbledore ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] SLOW
Just don't get both, or you may go to plaid... -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Boydell, Stuart Sent: October-08-11 7:28 AM To: U2 Users List Subject: Re: [U2] SLOW Wouldn't that mean xlr8ing? Sorry, couldn't resist either either :) -Original Message- From: Mecki Foerthmann Sent: Saturday, 8 October 2011 9:27 To: u2-users@listserver.u2ug.org Subject: Re: [U2] SLOW Maybe you should get him to buy FAST? sorry, couldn't resist either Mecki On 07/10/2011 21:21, Drew William Henderson wrote: with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] SLOW
with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] SLOW
Maybe you should get him to buy FAST? sorry, couldn't resist either Mecki On 07/10/2011 21:21, Drew William Henderson wrote: with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] SLOW
We've migrated from SLOW to CRAWL, and have found it be much less productive, and has increased the in house chatter with An emphasis on expletives! George -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Drew William Henderson Sent: Friday, October 07, 2011 4:21 PM To: U2-Users@listserver.u2ug.org Subject: [U2] SLOW with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] SLOW
Windows ? Linux ? On Fri, Oct 7, 2011 at 4:21 PM, Drew William Henderson d.hender...@moreheadstate.edu wrote: with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- *hp* ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] SLOW
There seems to be a direct correlation with either system (but more predominate on Windows) that, the longer it runs without a reboot, the greater the likelihood it's running SLOW. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Horacio Pellegrino Sent: Friday, October 07, 2011 4:50 PM To: U2 Users List Subject: Re: [U2] SLOW Windows ? Linux ? On Fri, Oct 7, 2011 at 4:21 PM, Drew William Henderson d.hender...@moreheadstate.edu wrote: with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- *hp* ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] SLOW
I use to work for a place that they THOUGHT they were running SLOW but it turned out it was an old copy of KARELuSS that had been infected by a lot of KNOTACLUE. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Drew William Henderson Sent: Friday, October 07, 2011 1:51 PM To: U2 Users List Subject: Re: [U2] SLOW There seems to be a direct correlation with either system (but more predominate on Windows) that, the longer it runs without a reboot, the greater the likelihood it's running SLOW. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Horacio Pellegrino Sent: Friday, October 07, 2011 4:50 PM To: U2 Users List Subject: Re: [U2] SLOW Windows ? Linux ? On Fri, Oct 7, 2011 at 4:21 PM, Drew William Henderson d.hender...@moreheadstate.edu wrote: with apologies to Jeff and Peggy...and, ok, everyone else, too! My boss has noticed today that we've been running SLOW, and isn't happy about it. He wants to know if SLOW is industry standard, and what other U2 shops might be running SLOW. I told him that I didn't know about other U2 shops, but that I know a lot of SQL shops have been running SLOW for years, and seem to be very satisfied. I also let him know that running SLOW on Friday afternoons was almost industry standard, but I'm not sure he's buying it. So, if you're running SLOW in your environment, please let me know; otherwise, we might not be running SLOW on Monday morning. (sorry...couldn't help myself! Have a good weekend, all!) Drew Henderson Director, Enterprise Systems Architecture and Security Morehead State University 301 Howell-McDowell Bldg Morehead, Ky 40351 606/783-2445 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- *hp* ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes (Nick Gettino)
Hundreds of characters.
My example concatenates a bunch of attributes like name and address together to
see if there are any matching records already on file, before creating a new
record. I set the alternate key length to 160 for this one index, and nothing
bad happened (so far).
I use that with the setindex, readfwd, etc unibasic commands in a subroutine to
return the matching record id, or nothing if not found.
Haven't had a need to go any bigger than that.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wally Terhune
Sent: Friday, September 10, 2010 4:04 PM
To: U2 Users List
Subject: Re: [U2] Slow READ/WRITE with indexes (Nick Gettino)
How long of a data string to you want to index?
This mostly has a bearing on the block-size of the index file (the key length
setting)
Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
Tel: +1.720.475.8055
Email: wterh...@rs.com
Web: www.rocketsoftware.com/u2
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Davis
Sent: Friday, September 10, 2010 1:24 PM
To: U2 Users List
Subject: Re: [U2] Slow READ/WRITE with indexes (Nick Gettino)
Does building the biggest first really matter, or is it more important to just
put the right value in the key size prompt you get asked for on the first
index you create?
Also, does anyone know in UniData how big a key size you can give on an index?
I know it's bigger than the 120-something you are limited to for the file key,
but I've never seen a documented limit.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Nick Gettino
Sent: Friday, September 10, 2010 3:19 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] Slow READ/WRITE with indexes (Nick Gettino)
On Unidata you can do a LIST.INDEX 'FILENAME' ALL STATS
This will give you each index the number of keys how many are in overflow and a
couple of other things.
If you can't tell from that command use
LIST.INDEX 'FILE.NAME' ALL DETAILS
This will show you how many records per key and whether the index item is in
overflow.
As mentioned use the NO.NULLS and or NO.DUPS to build the index.
And this has been a killer for us. You have to ALWAYS build the biggest index
first.
By biggest I mean the dictionary length being used.
Example. If you have city, state zip, order# and date. 40L, 15R, 8R
respectively that is how they should be built.
Nicholas M Gettino - Director of Support Professional Services | EnRoute
Emergency Systems an Infor Company, 401 E Jackson Street, Suite 1500, Tampa
Florida 33602 | Office 813-207-6998 |Fax 678-393-5389
|nick.gett...@enroute911.com / www.enroute911.com
Register Now- Early Bird Discount Available |
enroute911.com/user-conference-2010 | EnRoute User Conference | Disney's Yacht
Club Resort, Lake Buena Vista, FL | September 28- October 1, 2010
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
u2-users-requ...@listserver.u2ug.org
Sent: 09/10/2010 3:00 PM
To: u2-users@listserver.u2ug.org
Subject: U2-Users Digest, Vol 17, Issue 8
Send U2-Users mailing list submissions to
u2-users@listserver.u2ug.org
To subscribe or unsubscribe via the World Wide Web, visit
http://listserver.u2ug.org/mailman/listinfo/u2-users
or, via email, send a message with subject or body 'help' to
u2-users-requ...@listserver.u2ug.org
You can reach the person managing the list at
u2-users-ow...@listserver.u2ug.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of U2-Users digest...
Today's Topics:
1. Re: Sequential Files Question (Colin Alfke)
2. Re: Sequential Files Question (Bill Haskett)
3. Re: Slow READ/WRITE with indexes (Ryan M)
4. Re: Slow READ/WRITE with indexes (Ryan M)
5. Re: Slow READ/WRITE with indexes {Unclassified}
(HENDERSON MIKE, MR)
6. Re: Slow READ/WRITE with indexes (Colin Alfke)
7. Re: Sequential Files Question (Colin Alfke)
8. Re: Sequential Files Question (Bill Haskett)
9. Re: Slow READ/WRITE with indexes {Unclassified} (Wols Lists)
10. Re: Slow READ/WRITE with indexes {Unclassified} (Dan McGrath)
11. Re: Slow READ/WRITE with indexes (Boydell, Stuart)
12. Re: Slow READ/WRITE with indexes (Ryan M)
13. Re: Slow READ/WRITE with indexes {Unclassified} (Ryan M)
14. Re: Slow READ/WRITE with indexes (Ryan M)
15. UD - XDOMLocate problem - solved (Edward Brown)
16. Re: Slow READ/WRITE with indexes {Unclassified} (Wols Lists)
--
Message: 1
Date: Thu, 9 Sep 2010 13:02:10 -0600
From: Colin Alfke alfke...@hotmail.com
To: 'U2 Users List' u2-users@listserver.u2ug.org
Subject
Re: [U2] Slow READ/WRITE with indexes
Ryan, You've gotten some excellent suggestions here. Hopefully one or more will help. I've faced this same situation in EOM processing. What I ended up doing was copying the items from the main file (indexed) to a work file (not indexed) without deleting. I then fired off a phantom which copied the items from the work file to the history file (indexed), then deleted them from the main file. EOM was able to continue on after the items were first copied out. The index didn't interfere (in Jbase, at least), because no index updating was happening. As long as the items were out of the main file and into the history file before they were needed, all was OK. This required that I move the process toward the beginning of EOM, though. As always, your mileage may vary. Regards, Charlie Noah The views and opinions expressed herein are my own (Charlie Noah) and do not necessarily reflect the views, positions or policies of any of my former, current or future employers, employees, clients, friends, enemies or anyone else who might take exception to them. On 09-09-2010 12:28 PM, Larry Hiscock wrote: Are any of your indices based on virtual fields? I haven't worked with UV in a while, but UD has the DISABLE.INDEX, ENABLE.INDEX and UPDATE.INDEX commands. If UV also has them, you could disable the indexes prior to the archival and re-enable and update them at the end. I'm not sure if it would be any faster, but certainly worth an attempt. Larry Hiscock Western Computer Services -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ryan M Sent: Thursday, September 09, 2010 10:07 AM To: u2-users@listserver.u2ug.org Subject: [U2] Slow READ/WRITE with indexes I am hoping I can find some help here. I am running into a serious performance issue with indexes on our UV system (UV 10.2, on AIX). An example of this is our sales order files, SO (current/active) and SOH (history) files. We archive sales orders from SO to SOH on a daily basis, this is moving approx 15,000 records from one file to the other. If I remove all indexes from both files, the process flies by, hundreds of transactions per second. But, with indexes on, we are luck to get one per second. Basically what happens with the code that does the archiving is it reads the SO record, does some quick checks to make sure we can move it, then writes the record to SOH, then deletes the SO. There are 7 indexes on the SO file and 5 on the SOH. I've tried removing one index from a file and running the process, but see no performance gain until all indexes are gone. The SO file is approx 7GB with 280k records, and the SOH file is 11GB, with 8,900,000 records I have check the files sizes in UV and they are correct. Can anyone provide some pointers on ways to setup indexes so they will run faster? Some of the indexes are 'ORDER.DATE', 'COUNTRY', 'MEMBER ID' ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
Thanks, this what I'm finding too, and it's really bad news. Our database needs to be available 24/7 due to being in the international market. When disabling the index on the SO, then enabling and updating, the update causes locks the file - not good as our company runs off the SO file. Locking that file means we have scheduled downtime where we do no make money, the Powers That Be won't have any of that. Boydell, Stuart wrote: I have found that deletes are the hardest on index updating, slower than inserts. If you can, I'd specifically disable the delete from the SO file to see what change that makes. Cheers Stuart -Original Message- Basically what happens with the code that does the archiving is it reads the SO record, does some quick checks to make sure we can move it, then writes the record to SOH, then deletes the SO. There are 7 indexes on the SO file and 5 on the SOH. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29676533.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
Not sure what a vitural field is, is that like a foreign key? There is one index that is setup weird. Let me see if I can explain. We have multiple accounts of UV, one of them is a sql account, we'll call that uvsql. The SO table that is there has a dictionary/index of MEM_ID. That dictionary does not exist in the main account, uvmain. In the uvsql account an index was created called MEM_ID. There is no dictionary with that name but rather the dictionary is MEM.ID and SQL has problems with the . in the name. Would it be better to copy the dictionary MEM.ID to MEM_ID then re-create the index? Larry Hiscock wrote: Are any of your indices based on virtual fields? I haven't worked with UV in a while, but UD has the DISABLE.INDEX, ENABLE.INDEX and UPDATE.INDEX commands. If UV also has them, you could disable the indexes prior to the archival and re-enable and update them at the end. I'm not sure if it would be any faster, but certainly worth an attempt. Larry Hiscock Western Computer Services -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ryan M Sent: Thursday, September 09, 2010 10:07 AM To: u2-users@listserver.u2ug.org Subject: [U2] Slow READ/WRITE with indexes I am hoping I can find some help here. I am running into a serious performance issue with indexes on our UV system (UV 10.2, on AIX). An example of this is our sales order files, SO (current/active) and SOH (history) files. We archive sales orders from SO to SOH on a daily basis, this is moving approx 15,000 records from one file to the other. If I remove all indexes from both files, the process flies by, hundreds of transactions per second. But, with indexes on, we are luck to get one per second. Basically what happens with the code that does the archiving is it reads the SO record, does some quick checks to make sure we can move it, then writes the record to SOH, then deletes the SO. There are 7 indexes on the SO file and 5 on the SOH. I've tried removing one index from a file and running the process, but see no performance gain until all indexes are gone. The SO file is approx 7GB with 280k records, and the SOH file is 11GB, with 8,900,000 records I have check the files sizes in UV and they are correct. Can anyone provide some pointers on ways to setup indexes so they will run faster? Some of the indexes are 'ORDER.DATE', 'COUNTRY', 'MEMBER ID' -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29653705.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29676602.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes {Unclassified}
On 10/09/10 13:58, Ryan M wrote: So should the indexes be created with the NO.NULLS options? I can rebuild the indexes on our dev system with the NO.NULLs option as I'm pretty sure they are not using it. If any of the fields don't have any data in them they will index to null. This often results in a massive index record (and as others have said, massive index records clobber performance). NO.NULLS just stops any null records from being indexed. So if the index fields should always contain data of some sort, then the NO.NULLS option shouldn't make any difference. If the fields are often left blank, then yes it's a good idea to use the NO.NULLS option. Be aware, though, that one of the side effects is if you select for that field being blank, the index won't be used... If a blank entry is an error but sometimes happens and you want to fix them, then you don't want to use NO.NULLS because it makes finding the errors easier. Cheers, Wol Wols Lists wrote: On 09/09/10 21:29, HENDERSON MIKE, MR wrote: Ryan, You said you had indexes like 'ORDER.DATE', 'COUNTRY', 'MEMBER ID'. If those are really the full index data items, you could have thousands, tens of thousands, or even hundreds of thousands, of records with the identical index data item value in the SOH file. If that's the case, updates (inserts) may well be s-l-o-w as the system churns through many, many, many linked buffers of identical valued keys looking for an insert point. That was my thinking too. The other, related point. Does UD have NO.NULLS? And are you using it? If you haven't used it that's the most common performance-killer with indices out there ... Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Slow READ/WRITE with indexes (Nick Gettino)
all about pipe didn't it used to be | ? btw, even though I'm the admin on my laptop, it will not allow me to even use notepad to save to c:\buddy.txt Must be a new windows 7 thing. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message: 3 Date: Thu, 9 Sep 2010 13:10:54 -0700 (PDT) From: Ryan M rmcmul...@nsai.com To: u2-users@listserver.u2ug.org Subject: Re: [U2] Slow READ/WRITE with indexes Message-ID: 29670902.p...@talk.nabble.com Content-Type: text/plain; charset=us-ascii I'm trying this now, thanks. Larry Hiscock wrote: Are any of your indices based on virtual fields? I haven't worked with UV in a while, but UD has the DISABLE.INDEX, ENABLE.INDEX and UPDATE.INDEX commands. If UV also has them, you could disable the indexes prior to the archival and re-enable and update them at the end. I'm not sure if it would be any faster, but certainly worth an attempt. Larry Hiscock Western Computer Services -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ryan M Sent: Thursday, September 09, 2010 10:07 AM To: u2-users@listserver.u2ug.org Subject: [U2] Slow READ/WRITE with indexes I am hoping I can find some help here. I am running into a serious performance issue with indexes on our UV system (UV 10.2, on AIX). An example of this is our sales order files, SO (current/active) and SOH (history) files. We archive sales orders from SO to SOH on a daily basis, this is moving approx 15,000 records from one file to the other. If I remove all indexes from both files, the process flies by, hundreds of transactions per second. But, with indexes on, we are luck to get one per second. Basically what happens with the code that does the archiving is it reads the SO record, does some quick checks to make sure we can move it, then writes the record to SOH, then deletes the SO. There are 7 indexes on the SO file and 5 on the SOH. I've tried removing one index from a file and running the process, but see no performance gain until all indexes are gone. The SO file is approx 7GB with 280k records, and the SOH file is 11GB, with 8,900,000 records I have check the files sizes in UV and they are correct. Can anyone provide some pointers on ways to setup indexes so they will run faster? Some of the indexes are 'ORDER.DATE', 'COUNTRY', 'MEMBER ID' -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29653705.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29670902.html Sent from the U2 - Users mailing list archive at Nabble.com. -- Message: 4 Date: Thu, 9 Sep 2010 13:12:43 -0700 (PDT) From: Ryan M rmcmul...@nsai.com To: u2-users@listserver.u2ug.org Subject: Re: [U2] Slow READ/WRITE with indexes Message-ID: 29670926.p...@talk.nabble.com Content-Type: text/plain; charset=us-ascii The indexes have been in place for some time now (1+ years) I'm guessing 10k to 15k new records per day is fairly high volume (this does not include changes to existing records). bradley.schrag wrote: How long have these indexes been in place? If they're new, that's one thing. If they've been in place for a while and this is a change in behavior we may need to look in different areas. FYI, on ud I've had performance issues when going above five indexes on a given file when I have a high volume of transactions. Brad. U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- View this message in context: http
Re: [U2] Slow READ/WRITE with indexes (Nick Gettino)
Does building the biggest first really matter, or is it more important to just
put the right value in the key size prompt you get asked for on the first
index you create?
Also, does anyone know in UniData how big a key size you can give on an index?
I know it's bigger than the 120-something you are limited to for the file key,
but I've never seen a documented limit.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Nick Gettino
Sent: Friday, September 10, 2010 3:19 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] Slow READ/WRITE with indexes (Nick Gettino)
On Unidata you can do a LIST.INDEX 'FILENAME' ALL STATS
This will give you each index the number of keys how many are in overflow and a
couple of other things.
If you can't tell from that command use
LIST.INDEX 'FILE.NAME' ALL DETAILS
This will show you how many records per key and whether the index item is in
overflow.
As mentioned use the NO.NULLS and or NO.DUPS to build the index.
And this has been a killer for us. You have to ALWAYS build the biggest index
first.
By biggest I mean the dictionary length being used.
Example. If you have city, state zip, order# and date. 40L, 15R, 8R
respectively that is how they should be built.
Nicholas M Gettino - Director of Support Professional Services | EnRoute
Emergency Systems an Infor Company, 401 E Jackson Street, Suite 1500, Tampa
Florida 33602 | Office 813-207-6998 |Fax 678-393-5389
|nick.gett...@enroute911.com / www.enroute911.com
Register Now- Early Bird Discount Available |
enroute911.com/user-conference-2010 | EnRoute User Conference | Disney's Yacht
Club Resort, Lake Buena Vista, FL | September 28- October 1, 2010
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
u2-users-requ...@listserver.u2ug.org
Sent: 09/10/2010 3:00 PM
To: u2-users@listserver.u2ug.org
Subject: U2-Users Digest, Vol 17, Issue 8
Send U2-Users mailing list submissions to
u2-users@listserver.u2ug.org
To subscribe or unsubscribe via the World Wide Web, visit
http://listserver.u2ug.org/mailman/listinfo/u2-users
or, via email, send a message with subject or body 'help' to
u2-users-requ...@listserver.u2ug.org
You can reach the person managing the list at
u2-users-ow...@listserver.u2ug.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of U2-Users digest...
Today's Topics:
1. Re: Sequential Files Question (Colin Alfke)
2. Re: Sequential Files Question (Bill Haskett)
3. Re: Slow READ/WRITE with indexes (Ryan M)
4. Re: Slow READ/WRITE with indexes (Ryan M)
5. Re: Slow READ/WRITE with indexes {Unclassified}
(HENDERSON MIKE, MR)
6. Re: Slow READ/WRITE with indexes (Colin Alfke)
7. Re: Sequential Files Question (Colin Alfke)
8. Re: Sequential Files Question (Bill Haskett)
9. Re: Slow READ/WRITE with indexes {Unclassified} (Wols Lists)
10. Re: Slow READ/WRITE with indexes {Unclassified} (Dan McGrath)
11. Re: Slow READ/WRITE with indexes (Boydell, Stuart)
12. Re: Slow READ/WRITE with indexes (Ryan M)
13. Re: Slow READ/WRITE with indexes {Unclassified} (Ryan M)
14. Re: Slow READ/WRITE with indexes (Ryan M)
15. UD - XDOMLocate problem - solved (Edward Brown)
16. Re: Slow READ/WRITE with indexes {Unclassified} (Wols Lists)
--
Message: 1
Date: Thu, 9 Sep 2010 13:02:10 -0600
From: Colin Alfke alfke...@hotmail.com
To: 'U2 Users List' u2-users@listserver.u2ug.org
Subject: Re: [U2] Sequential Files Question
Message-ID: snt139-ds5e54ede19399d72b0201898...@phx.gbl
Content-Type: text/plain; charset=us-ascii
The pipe is different. I use it to send output as input to other commands:
!LISTUSER | MORE or
!LISTUSER | FIND COLIN /I
But then I've only been really using DOS since 3.11
I've noticed Win 7 hides the root of C:, but I didn't realize that it
wouldn't let you create a file.
Colin
-Original Message-
From: Allen Elwood
I've been using DOS since 1.0 - forgot all about pipe didn't it
used to be | ?
btw, even though I'm the admin on my laptop, it will not allow me to
even use notepad to save to c:\buddy.txt
Must be a new windows 7 thing.
--
Message: 2
Date: Thu, 09 Sep 2010 12:33:19 -0700
From: Bill Haskett wphask...@advantos.net
To: U2 Users List u2-users@listserver.u2ug.org
Subject: Re: [U2] Sequential Files Question
Message-ID: 4c89367f.6020...@advantos.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Colin:
I wonder if Windows 7 complains about any writes to the C:\ drive.
This would be a good thing, but still, some applications install into
C:\Program Files (x86), so that directory must allow writes along with
C:\ProgramData (notice how they seem to have removed their heads from
that dark space
Re: [U2] Slow READ/WRITE with indexes (Nick Gettino)
How long of a data string to you want to index?
This mostly has a bearing on the block-size of the index file (the key length
setting)
Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
Tel: +1.720.475.8055
Email: wterh...@rs.com
Web: www.rocketsoftware.com/u2
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Davis
Sent: Friday, September 10, 2010 1:24 PM
To: U2 Users List
Subject: Re: [U2] Slow READ/WRITE with indexes (Nick Gettino)
Does building the biggest first really matter, or is it more important to just
put the right value in the key size prompt you get asked for on the first
index you create?
Also, does anyone know in UniData how big a key size you can give on an index?
I know it's bigger than the 120-something you are limited to for the file key,
but I've never seen a documented limit.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Nick Gettino
Sent: Friday, September 10, 2010 3:19 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] Slow READ/WRITE with indexes (Nick Gettino)
On Unidata you can do a LIST.INDEX 'FILENAME' ALL STATS
This will give you each index the number of keys how many are in overflow and a
couple of other things.
If you can't tell from that command use
LIST.INDEX 'FILE.NAME' ALL DETAILS
This will show you how many records per key and whether the index item is in
overflow.
As mentioned use the NO.NULLS and or NO.DUPS to build the index.
And this has been a killer for us. You have to ALWAYS build the biggest index
first.
By biggest I mean the dictionary length being used.
Example. If you have city, state zip, order# and date. 40L, 15R, 8R
respectively that is how they should be built.
Nicholas M Gettino - Director of Support Professional Services | EnRoute
Emergency Systems an Infor Company, 401 E Jackson Street, Suite 1500, Tampa
Florida 33602 | Office 813-207-6998 |Fax 678-393-5389
|nick.gett...@enroute911.com / www.enroute911.com
Register Now- Early Bird Discount Available |
enroute911.com/user-conference-2010 | EnRoute User Conference | Disney's Yacht
Club Resort, Lake Buena Vista, FL | September 28- October 1, 2010
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
u2-users-requ...@listserver.u2ug.org
Sent: 09/10/2010 3:00 PM
To: u2-users@listserver.u2ug.org
Subject: U2-Users Digest, Vol 17, Issue 8
Send U2-Users mailing list submissions to
u2-users@listserver.u2ug.org
To subscribe or unsubscribe via the World Wide Web, visit
http://listserver.u2ug.org/mailman/listinfo/u2-users
or, via email, send a message with subject or body 'help' to
u2-users-requ...@listserver.u2ug.org
You can reach the person managing the list at
u2-users-ow...@listserver.u2ug.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of U2-Users digest...
Today's Topics:
1. Re: Sequential Files Question (Colin Alfke)
2. Re: Sequential Files Question (Bill Haskett)
3. Re: Slow READ/WRITE with indexes (Ryan M)
4. Re: Slow READ/WRITE with indexes (Ryan M)
5. Re: Slow READ/WRITE with indexes {Unclassified}
(HENDERSON MIKE, MR)
6. Re: Slow READ/WRITE with indexes (Colin Alfke)
7. Re: Sequential Files Question (Colin Alfke)
8. Re: Sequential Files Question (Bill Haskett)
9. Re: Slow READ/WRITE with indexes {Unclassified} (Wols Lists)
10. Re: Slow READ/WRITE with indexes {Unclassified} (Dan McGrath)
11. Re: Slow READ/WRITE with indexes (Boydell, Stuart)
12. Re: Slow READ/WRITE with indexes (Ryan M)
13. Re: Slow READ/WRITE with indexes {Unclassified} (Ryan M)
14. Re: Slow READ/WRITE with indexes (Ryan M)
15. UD - XDOMLocate problem - solved (Edward Brown)
16. Re: Slow READ/WRITE with indexes {Unclassified} (Wols Lists)
--
Message: 1
Date: Thu, 9 Sep 2010 13:02:10 -0600
From: Colin Alfke alfke...@hotmail.com
To: 'U2 Users List' u2-users@listserver.u2ug.org
Subject: Re: [U2] Sequential Files Question
Message-ID: snt139-ds5e54ede19399d72b0201898...@phx.gbl
Content-Type: text/plain; charset=us-ascii
The pipe is different. I use it to send output as input to other commands:
!LISTUSER | MORE or
!LISTUSER | FIND COLIN /I
But then I've only been really using DOS since 3.11
I've noticed Win 7 hides the root of C:, but I didn't realize that it
wouldn't let you create a file.
Colin
-Original Message-
From: Allen Elwood
I've been using DOS since 1.0 - forgot all about pipe didn't it
used to be | ?
btw, even though I'm the admin on my laptop, it will not allow me to
even use notepad to save to c:\buddy.txt
Must be a new windows 7 thing
Re: [U2] Slow READ/WRITE with indexes
Key Size Block Size Key Size Block Size 1-13 2,048 137-177 10,240 14-54 4,096 178-218 12,288 55-95 6,144 219-259 14,336 96-136 8,192 260-300 16,384 Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wally Terhune Sent: Friday, September 10, 2010 2:04 PM To: U2 Users List Subject: Re: [U2] Slow READ/WRITE with indexes (Nick Gettino) How long of a data string to you want to index? This mostly has a bearing on the block-size of the index file (the key length setting) ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
Hmm - table didn't get handled well by MS mail Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wally Terhune Sent: Friday, September 10, 2010 2:09 PM To: U2 Users List Subject: Re: [U2] Slow READ/WRITE with indexes Key Size Block Size Key Size Block Size 1-13 2,048 137-177 10,240 14-54 4,096 178-218 12,288 55-95 6,144 219-259 14,336 96-136 8,192 260-300 16,384 Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wally Terhune Sent: Friday, September 10, 2010 2:04 PM To: U2 Users List Subject: Re: [U2] Slow READ/WRITE with indexes (Nick Gettino) How long of a data string to you want to index? This mostly has a bearing on the block-size of the index file (the key length setting) ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
I get your point though - it matches my result - 10K block size for 160 key size. It does what I need it to do though. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wally Terhune Sent: Friday, September 10, 2010 4:12 PM To: U2 Users List Subject: Re: [U2] Slow READ/WRITE with indexes Hmm - table didn't get handled well by MS mail Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wally Terhune Sent: Friday, September 10, 2010 2:09 PM To: U2 Users List Subject: Re: [U2] Slow READ/WRITE with indexes Key Size Block Size Key Size Block Size 1-13 2,048 137-177 10,240 14-54 4,096 178-218 12,288 55-95 6,144 219-259 14,336 96-136 8,192 260-300 16,384 Wally Terhune U2 Support Architect Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA Tel: +1.720.475.8055 Email: wterh...@rs.com Web: www.rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wally Terhune Sent: Friday, September 10, 2010 2:04 PM To: U2 Users List Subject: Re: [U2] Slow READ/WRITE with indexes (Nick Gettino) How long of a data string to you want to index? This mostly has a bearing on the block-size of the index file (the key length setting) ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users html body Dave Davis Team Lead, Ramp;D P: 614-875-4910 x108 F: 614-875-4088 E: dda...@harriscomputer.com [http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] [http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif] 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. /body /html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Slow READ/WRITE with indexes
I am hoping I can find some help here. I am running into a serious performance issue with indexes on our UV system (UV 10.2, on AIX). An example of this is our sales order files, SO (current/active) and SOH (history) files. We archive sales orders from SO to SOH on a daily basis, this is moving approx 15,000 records from one file to the other. If I remove all indexes from both files, the process flies by, hundreds of transactions per second. But, with indexes on, we are luck to get one per second. Basically what happens with the code that does the archiving is it reads the SO record, does some quick checks to make sure we can move it, then writes the record to SOH, then deletes the SO. There are 7 indexes on the SO file and 5 on the SOH. I've tried removing one index from a file and running the process, but see no performance gain until all indexes are gone. The SO file is approx 7GB with 280k records, and the SOH file is 11GB, with 8,900,000 records I have check the files sizes in UV and they are correct. Can anyone provide some pointers on ways to setup indexes so they will run faster? Some of the indexes are 'ORDER.DATE', 'COUNTRY', 'MEMBER ID' -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29653705.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
Are any of your indices based on virtual fields? I haven't worked with UV in a while, but UD has the DISABLE.INDEX, ENABLE.INDEX and UPDATE.INDEX commands. If UV also has them, you could disable the indexes prior to the archival and re-enable and update them at the end. I'm not sure if it would be any faster, but certainly worth an attempt. Larry Hiscock Western Computer Services -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ryan M Sent: Thursday, September 09, 2010 10:07 AM To: u2-users@listserver.u2ug.org Subject: [U2] Slow READ/WRITE with indexes I am hoping I can find some help here. I am running into a serious performance issue with indexes on our UV system (UV 10.2, on AIX). An example of this is our sales order files, SO (current/active) and SOH (history) files. We archive sales orders from SO to SOH on a daily basis, this is moving approx 15,000 records from one file to the other. If I remove all indexes from both files, the process flies by, hundreds of transactions per second. But, with indexes on, we are luck to get one per second. Basically what happens with the code that does the archiving is it reads the SO record, does some quick checks to make sure we can move it, then writes the record to SOH, then deletes the SO. There are 7 indexes on the SO file and 5 on the SOH. I've tried removing one index from a file and running the process, but see no performance gain until all indexes are gone. The SO file is approx 7GB with 280k records, and the SOH file is 11GB, with 8,900,000 records I have check the files sizes in UV and they are correct. Can anyone provide some pointers on ways to setup indexes so they will run faster? Some of the indexes are 'ORDER.DATE', 'COUNTRY', 'MEMBER ID' -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29653705.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
How long have these indexes been in place? If they're new, that's one thing. If they've been in place for a while and this is a change in behavior we may need to look in different areas. FYI, on ud I've had performance issues when going above five indexes on a given file when I have a high volume of transactions. Brad. U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
what sofware package are you running there at usbank ? --- On Thu, 9/9/10, bradley.sch...@usbank.com bradley.sch...@usbank.com wrote: From: bradley.sch...@usbank.com bradley.sch...@usbank.com Subject: Re: [U2] Slow READ/WRITE with indexes To: U2 Users List u2-users@listserver.u2ug.org Date: Thursday, September 9, 2010, 2:39 PM How long have these indexes been in place? If they're new, that's one thing. If they've been in place for a while and this is a change in behavior we may need to look in different areas. FYI, on ud I've had performance issues when going above five indexes on a given file when I have a high volume of transactions. Brad. U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
I'm trying this now, thanks. Larry Hiscock wrote: Are any of your indices based on virtual fields? I haven't worked with UV in a while, but UD has the DISABLE.INDEX, ENABLE.INDEX and UPDATE.INDEX commands. If UV also has them, you could disable the indexes prior to the archival and re-enable and update them at the end. I'm not sure if it would be any faster, but certainly worth an attempt. Larry Hiscock Western Computer Services -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ryan M Sent: Thursday, September 09, 2010 10:07 AM To: u2-users@listserver.u2ug.org Subject: [U2] Slow READ/WRITE with indexes I am hoping I can find some help here. I am running into a serious performance issue with indexes on our UV system (UV 10.2, on AIX). An example of this is our sales order files, SO (current/active) and SOH (history) files. We archive sales orders from SO to SOH on a daily basis, this is moving approx 15,000 records from one file to the other. If I remove all indexes from both files, the process flies by, hundreds of transactions per second. But, with indexes on, we are luck to get one per second. Basically what happens with the code that does the archiving is it reads the SO record, does some quick checks to make sure we can move it, then writes the record to SOH, then deletes the SO. There are 7 indexes on the SO file and 5 on the SOH. I've tried removing one index from a file and running the process, but see no performance gain until all indexes are gone. The SO file is approx 7GB with 280k records, and the SOH file is 11GB, with 8,900,000 records I have check the files sizes in UV and they are correct. Can anyone provide some pointers on ways to setup indexes so they will run faster? Some of the indexes are 'ORDER.DATE', 'COUNTRY', 'MEMBER ID' -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29653705.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29670902.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
The indexes have been in place for some time now (1+ years) I'm guessing 10k to 15k new records per day is fairly high volume (this does not include changes to existing records). bradley.schrag wrote: How long have these indexes been in place? If they're new, that's one thing. If they've been in place for a while and this is a change in behavior we may need to look in different areas. FYI, on ud I've had performance issues when going above five indexes on a given file when I have a high volume of transactions. Brad. U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- View this message in context: http://old.nabble.com/Slow-READ-WRITE-with-indexes-tp29653705p29670926.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes {Unclassified}
Ryan, You said you had indexes like 'ORDER.DATE', 'COUNTRY', 'MEMBER ID'. If those are really the full index data items, you could have thousands, tens of thousands, or even hundreds of thousands, of records with the identical index data item value in the SOH file. If that's the case, updates (inserts) may well be s-l-o-w as the system churns through many, many, many linked buffers of identical valued keys looking for an insert point. I'd try to isolate if the problem is with deletes from the SO file or inserts to the SOH file, by disabling indexing first on one, then the other, then both, to see where the problem lies. If it's inserts to the SOH file that's the problem - which I suspect is the case - then you have two choices: make the disabling of indexes during this process a 'feature'; or restructure your SOH file and its indexes to avoid the clumping. The restructuring could involve re-defining your indexed fields to give fewer duplicated values (but that might mean considerable application program changes, depending how they're written) or you could consider turning SOH into a UV Distributed File set, maybe partitioning on values of ORDER.DATE. Good hunting Mike -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ryan M Sent: Friday, 10 September 2010 8:13 a.m. To: u2-users@listserver.u2ug.org Subject: Re: [U2] Slow READ/WRITE with indexes The indexes have been in place for some time now (1+ years) I'm guessing 10k to 15k new records per day is fairly high volume (this does not include changes to existing records). The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
Make sure you do some testing first. Under UniData I found that disabling the index made things much worse. It created a log file and put a copy of each record (appears to be the entire record - and not optimized for just the required index info) into it. The bad part was we were building a reporting cube so each record was written many times - which were all in the log file. This created a HUGE log file and was actually slower than leaving the index disabled. Plus it had to apply each of these records once we re-enabled/updated the index. It was actually much faster to remove the index, build the file, and then rebuild the index. Maybe it's better now - or maybe it just wasn't designed for what we were doing Hth Colin Alfke Calgary, Canada -Original Message- From: Ryan M I'm trying this now, thanks. Larry Hiscock wrote: Are any of your indices based on virtual fields? I haven't worked with UV in a while, but UD has the DISABLE.INDEX, ENABLE.INDEX and UPDATE.INDEX commands. If UV also has them, you could disable the indexes prior to the archival and re-enable and update them at the end. I'm not sure if it would be any faster, but certainly worth an attempt. Larry Hiscock Western Computer Services ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes {Unclassified}
On 09/09/10 21:29, HENDERSON MIKE, MR wrote: Ryan, You said you had indexes like 'ORDER.DATE', 'COUNTRY', 'MEMBER ID'. If those are really the full index data items, you could have thousands, tens of thousands, or even hundreds of thousands, of records with the identical index data item value in the SOH file. If that's the case, updates (inserts) may well be s-l-o-w as the system churns through many, many, many linked buffers of identical valued keys looking for an insert point. That was my thinking too. The other, related point. Does UD have NO.NULLS? And are you using it? If you haven't used it that's the most common performance-killer with indices out there ... Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow READ/WRITE with indexes
I have found that deletes are the hardest on index updating, slower than inserts. If you can, I'd specifically disable the delete from the SO file to see what change that makes. Cheers Stuart -Original Message- Basically what happens with the code that does the archiving is it reads the SO record, does some quick checks to make sure we can move it, then writes the record to SOH, then deletes the SO. There are 7 indexes on the SO file and 5 on the SOH. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow Universe/Win processes dropping
I've been hoping to learn about some setting that would cause processes to auto-terminate when the client drops. For example in D3 there is a setting called DCD-ON, which was designed for serial processes to do a Data Carrier Detect, but it allows D3 to auto-drop dead telnet processes as well. Might UV have some sort of heartbeat function, where lack of heartbeat from a telnet or UO client means it's dead and it's time to, uh, bury the connection? Thanks again, T From: Kurt Neumann UniVerse for Windows ships with its own kill which is found in the uv/bin. From:Boydell, Stuart We used to determine the process id and use kill (found in the Windows SDK) to kill the process. UV is then pretty good at clearing up locks etc. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow Universe/Win processes dropping
For UO there is a timeout setting. I do not think there is one for uv telnet tho. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: 28 December 2009 19:21 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Slow Universe/Win processes dropping I've been hoping to learn about some setting that would cause processes to auto-terminate when the client drops. For example in D3 there is a setting called DCD-ON, which was designed for serial processes to do a Data Carrier Detect, but it allows D3 to auto-drop dead telnet processes as well. Might UV have some sort of heartbeat function, where lack of heartbeat from a telnet or UO client means it's dead and it's time to, uh, bury the connection? Thanks again, T From: Kurt Neumann UniVerse for Windows ships with its own kill which is found in the uv/bin. From:Boydell, Stuart We used to determine the process id and use kill (found in the Windows SDK) to kill the process. UV is then pretty good at clearing up locks etc. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow Universe/Win processes dropping
Stuart UniVerse for Windows ships with its own kill which is found in the uv/bin. Thanks Kurt Neumann -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Boydell, Stuart Sent: 27 December 2009 04:22 AM To: U2 Users List Subject: Re: [U2] Slow Universe/Win processes dropping We used to determine the process id and use kill (found in the Windows SDK) to kill the process. UV is then pretty good at clearing up locks etc. Stuart Boydell -Original Message- My question is: what are the current/best mechanisms for getting Universe/Windows to promptly terminate Telnet and UO connections when the client has gone away? ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery and then delete it and your reply. It is your responsibility to check this email and any attachments for viruses and defects before opening or sending them on. Spotless collects information about you to provide and market our services. For information about use, disclosure and access, see our privacy policy at http://www.spotless.com.au Please consider our environment before printing this email. ** ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Pinnacle Technology Holdings E-Mail Disclaimer: This e-mail is confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Pinnacle Technology Holdings any of it's divisions or affiliates. If you are not the intended recipient, be advised that you have this e-mail in error and that any use, dissemination, forwarding, printing, or copying of it is strictly prohibited. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow Universe/Win processes dropping
Hi Tony This one is a pain. Uniadmin is possibly the best option, however it is not always effective and straight away plus you really bang your head on the wall if a record is locked by one of those processes. Regards David -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Thursday, 24 December 2009 6:41 AM To: u2-users@listserver.u2ug.org Subject: [U2] Slow Universe/Win processes dropping One of our clients with Universe over Windows has something causing their system to periodically run Very slowly with high CPU utilization. Rocket Support is on it. Until the core issue is resolved, client/server interfaces via UO.NET and Telnet will see that the server is not responsive for some period of time, and all they can do is disconnect the client side. Of course the server side can't be disconnected in this scenario, and unfortunately the connections aren't automatically dropping when the CPU comes available again. My question is: what are the current/best mechanisms for getting Universe/Windows to promptly terminate Telnet and UO connections when the client has gone away? Thanks! Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! http://Twitter.com/TonyGravagno ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow Universe/Win processes dropping
We used to determine the process id and use kill (found in the Windows SDK) to kill the process. UV is then pretty good at clearing up locks etc. Stuart Boydell -Original Message- My question is: what are the current/best mechanisms for getting Universe/Windows to promptly terminate Telnet and UO connections when the client has gone away? ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery and then delete it and your reply. It is your responsibility to check this email and any attachments for viruses and defects before opening or sending them on. Spotless collects information about you to provide and market our services. For information about use, disclosure and access, see our privacy policy at http://www.spotless.com.au Please consider our environment before printing this email. ** ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Slow Universe/Win processes dropping
One of our clients with Universe over Windows has something causing their system to periodically run Very slowly with high CPU utilization. Rocket Support is on it. Until the core issue is resolved, client/server interfaces via UO.NET and Telnet will see that the server is not responsive for some period of time, and all they can do is disconnect the client side. Of course the server side can't be disconnected in this scenario, and unfortunately the connections aren't automatically dropping when the CPU comes available again. My question is: what are the current/best mechanisms for getting Universe/Windows to promptly terminate Telnet and UO connections when the client has gone away? Thanks! Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! http://Twitter.com/TonyGravagno ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Slow selects
We are running Unidata 7.1 on a linux box (Red Hat Enterprise Linux ES release 4 (Nahant Update 4) Kernel 2.6.9-42.ELsmp on an i686). For some reason I cannot fathom, the first time you perform any Uniquery command on a file it takes forever to return. Say, 5 minutes. Subsequent queries on the same file, with different criteria (or the same), take seconds, say 10. This is generally on static, hashed files with lots of level 1 overflow, but no level 2 overflow. This is a pretty fast environment with this weird exception. Any ideas about what the problem might be? Thanks, Kebbon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow selects
The first pass on a file has to start from scratch. Once it has been read and is still fresh in memory, a 2nd pass will run much faster. John Israel Sr. Programmer/Analyst Dayton Superior Corporation 721 Richard St. Dayton, OH 45342 937-866-0711 x44380 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kebbon Irwin Sent: Thursday, July 30, 2009 10:58 AM To: u2-users@listserver.u2ug.org Subject: [U2] Slow selects We are running Unidata 7.1 on a linux box (Red Hat Enterprise Linux ES release 4 (Nahant Update 4) Kernel 2.6.9-42.ELsmp on an i686). For some reason I cannot fathom, the first time you perform any Uniquery command on a file it takes forever to return. Say, 5 minutes. Subsequent queries on the same file, with different criteria (or the same), take seconds, say 10. This is generally on static, hashed files with lots of level 1 overflow, but no level 2 overflow. This is a pretty fast environment with this weird exception. Any ideas about what the problem might be? Thanks, Kebbon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Slow selects
And that will only last for a while before that information is flushed from memory. David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office:810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services, and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R. Sent: Thursday, July 30, 2009 11:03 AM To: 'U2 Users List' Subject: Re: [U2] Slow selects The first pass on a file has to start from scratch. Once it has been read and is still fresh in memory, a 2nd pass will run much faster. John Israel Sr. Programmer/Analyst Dayton Superior Corporation 721 Richard St. Dayton, OH 45342 937-866-0711 x44380 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kebbon Irwin Sent: Thursday, July 30, 2009 10:58 AM To: u2-users@listserver.u2ug.org Subject: [U2] Slow selects We are running Unidata 7.1 on a linux box (Red Hat Enterprise Linux ES release 4 (Nahant Update 4) Kernel 2.6.9-42.ELsmp on an i686). For some reason I cannot fathom, the first time you perform any Uniquery command on a file it takes forever to return. Say, 5 minutes. Subsequent queries on the same file, with different criteria (or the same), take seconds, say 10. This is generally on static, hashed files with lots of level 1 overflow, but no level 2 overflow. This is a pretty fast environment with this weird exception. Any ideas about what the problem might be? Thanks, Kebbon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
RE: [U2] Slow uniobjects connections
Marc Sorry I missed the original post. Are you connecting using the host name or directly specifying the IP address? Host name lookups can sometimes be slow. Also how are you authenticating the user ? If you are on Windows using domain credentials that can be a bottleneck. If the connection is coming in from a single ASP site you could create a local user on your UniVerse server and see it that is any quicker to authenticate. Regards, Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cordes, Tom (contractor) Sent: 13 November 2006 16:44 To: 'u2-users@listserver.u2ug.org' Subject: RE: [U2] Slow uniobjects connections Marc, Is the 'slow' speed compared to a uniobjects connection made some other way? Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Hilbert Sent: Thursday, November 09, 2006 6:12 PM To: u2-users@listserver.u2ug.org Subject: [U2] Slow uniobjects connections Good evening, We are experiencing very slow uniobjects (one second to connect) connections from a DLL which is called from an ASP server aplication. (W2K, UV 10.1). Does anyone have any experience to share regarding this? Thanks in advance, Marc --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Slow uniobjects connections
Hi - I actually had a problem on a w2k3 machine running iis6 where only one uniobjects connection per asp worker process w3p.exe was possible - this made it look very slow - I am not sure where the problem was with this as we re-wrote it in asp.net and it was fine rgds Symeon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Hilbert Sent: Thursday, November 09, 2006 6:12 PM To: u2-users@listserver.u2ug.org Subject: [U2] Slow uniobjects connections Good evening, We are experiencing very slow uniobjects (one second to connect) connections from a DLL which is called from an ASP server aplication. (W2K, UV 10.1). Does anyone have any experience to share regarding this? Thanks in advance, Marc --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Slow uniobjects connections
Marc, Is the 'slow' speed compared to a uniobjects connection made some other way? Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Hilbert Sent: Thursday, November 09, 2006 6:12 PM To: u2-users@listserver.u2ug.org Subject: [U2] Slow uniobjects connections Good evening, We are experiencing very slow uniobjects (one second to connect) connections from a DLL which is called from an ASP server aplication. (W2K, UV 10.1). Does anyone have any experience to share regarding this? Thanks in advance, Marc --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Slow uniobjects connections
Good evening, We are experiencing very slow uniobjects (one second to connect) connections from a DLL which is called from an ASP server aplication. (W2K, UV 10.1). Does anyone have any experience to share regarding this? Thanks in advance, Marc --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Slow ascii output
Well said, Mark. My opportunity to really learn about Pick performance was circa 1985 on an ADDS 1500, a PC XT clone with 256K RAM, a 10MB hard drive and a port of the ADDS Mentor Pick O/S. We ported some code from an ADDS 4000 to it and I was shocked to see how slowly a 3-column screen of multivalued data displayed on the 1500. The code was a for-next loop to display REC23,X , REC24,X and REC25,X. Took about one-half second per cell, or about half a minute per 20-line by 3-column screen! So the 1500 was slow enough to make the internal workings of Pick (and Unidata today) visible to the user: (1) the data was deep enough in the record to cause a frame-fault and (2) dynamic arrays find the requested data by searching forward from the first character of the record each time they're referenced, so the record was being scanned 60 times per screenful. The solution was simple: assign each attribute to its own variable before the display loop, display the variables (e.g. PRICE1,X rather than REC24,X), and voila!, the screen became nice and fast again. Hunting down (or better yet, avoiding) performance issues on modern systems is a lot easier having seen similar behavior on older, slower machines. Have fun, Tom [EMAIL PROTECTED] 10/21/06 9:43 PM Keep in mind that 16MB for 32 users is 250 times the memory available circa late 1970s' with the Microdata Royale series. There's something to be said for programming on an older system that gives you respect for todays horsepower. snip - This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the LabCorp Privacy Officer at [EMAIL PROTECTED] or call (877) 23-HIPAA / (877) 234-4722. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Slow ascii output
The c/r delay may have had something to do with it. PRINT expression: ran faster than PRINT expression and If you had lots of PRINTs Does anyone out there remember the Newt, the Visa and also (perchance) where the MV file transfer protocol based on More Tea Vicar got it's name? McD Reality - (exchangeable hard disk packs) - (gosh). I remember building the whole screen template into a single variable to PRINT it without undue delays. Doing the same with the screen variable content for a second PRINT to keep savings there as well. One night a SYSOP did a Disk Pack Set copy of C (oldest)- A (current) instead of A (current) - C (oldest) - gosh what fun.. Was it: INT-CLOCK-SS1-LOAD-RUN or INT-CLOCK-RESET-SS1-LOAD-RUN? !PCB.182;2 . = .0184 Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Slow ascii output
On Fri, 20 Oct 2006, Kevin King wrote: Jeff, why WRITESEQF instead of WRITESEQ? You're completely undermining write buffering with WRITESEQF are you not? I think this may be from an example where I was debugging code and used WRITESEQF to ensure that all I/O was written before the program crashed. It may be a fluke but I'll check my code to be sure. Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 I'm not grumpy Daddy, I'm whining. my 3-year old showing her wisdom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Slow ascii output
On Fri, 20 Oct 2006, Anthony W. Youngman wrote: Our system was short of RAM - 16 meg for 32 users (PI/Open on an EXL 7330). It thrashed enough under normal load, even before you started to try and build large (and I mean LARGE) strings in BASIC... We don't have this issue - we have 16Gig for about 90 users. Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 I'm not grumpy Daddy, I'm whining. my 3-year old showing her wisdom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Slow ascii output
Mark Johnson wrote on 10/21/2006 09:43:13 PM: Keep in mind that 16MB for 32 users is 250 times the memory available circa late 1970s' with the Microdata Royale series. There's something to be said for programming on an older system that gives you respect for todays horsepower. I agree 100%. In the late 70s I was working at a Savings and Loan with seven branch offices. There were several teller terminals and one or two VDTs at each branch. We ran with a grand total of 256 KB (not MB - KB) of memory - and that was after the upgrade from 128 KB. [Hey, it seemed like a lot because my TRS-80 only had 4 KB ;-)] You learned to be very efficient. And we couldn't make any programming mistakes. Our online program took all night to compile. We kept a few KB of memory set aside in the program so we could patch in hex code and branch in and out of the main program. At the end of the online day we rebooted the system with different memory parameters for nightly batch processing. Ah, the good old days... Tim Snyder Consulting I/T Specialist U2 Consulting North American Lab Services IBM Software Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Slow ascii output
Keep in mind that 16MB for 32 users is 250 times the memory available circa late 1970s' with the Microdata Royale series. There's something to be said for programming on an older system that gives you respect for todays horsepower. I experience this first hand every other week when visiting my Microdata client from my normal U2/D3 client base. While you can't get really technically sophisticated as with the current systems, you do become more effecient when programming within limits. Perhaps the single thing I miss the most when programming on this old system is the fact that I cannot use external subroutiness as freely as on every other platform. I have a whole bunch of handy subs that I install on all of my clients but have to convert them to INCLUDES if I want to use them there. Microdatas don't like mixing RUN and cataloged programs together. My 1 cent. Mark Johnson - Original Message - From: Anthony W. Youngman [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Saturday, October 21, 2006 6:29 PM Subject: Re: [U2] Slow ascii output In message [EMAIL PROTECTED], Claus Derlien [EMAIL PROTECTED] writes no one and I mean NO ONE uses a system with 16 MB ram today! we have 65 users on 2 gig ram, and when we do payments of unemployment salaries to our members we do everything in memory, and just write the edi file to a record a large batch takes less than two minutes and it also generates payment specifications for storage in pdf format (using cross pdf package). oh and we also do an xml conversion of the edi file on the fly aswell.. UniVerse is really a top performer when it comes to number crunching and file management how do you power a 16 meg system today ?? - with steam ? Note the use of the PAST tense. That machine is now salvage in my garage, waiting for me to restore it to personal use. I was just pointing out that MMV, and some things may work for some people and not for others. Why we were trying to run 32 users on 16 meg, even when the system was brand new (1990ish), I don't know. Penny-pinching, I guess. It's just that WRITESEQ makes a lot of sense when you're building BIG strings and are short of RAM... Med venlig hilsen Claus Derlien programmxr Edb-afdelingen Cheers, Wol Our system was short of RAM - 16 meg for 32 users (PI/Open on an EXL 7330). It thrashed enough under normal load, even before you started to try and build large (and I mean LARGE) strings in BASIC... Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Slow ascii output
I'm going to ask yet another dumb question - Unidata 6.1.4 on Solaris (soon to be 7.1.x). I'm selecting a bunch of records and then outputting data from them into an ascii file in _HOLD_. If I open a sequential file, write the data line-by-line (WRITESEQF) and close the file, it takes about 5 minutes. If I save the data in a @FM delimited record and then write the record out at the end, it takes about 3 seconds. I'm well aware that writing sequentially is doing a whole lot more disk I/O but I can't believe the difference in speed. Are their any subtleties other than disk I/O? I seem to recall some discussion about seq files and maintaining the pointer of where the current position in the file, but I'm foggy on these topics... -- Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 ...our behavior matters more than the beliefs that we profess. Elizabeth Deutsch Earle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Slow ascii output
Hi Jeff, Couple of ideas: -1- Try WRITESEQ instead of WRITESEQF so the system will buffer your output in memory and write it to disk in more efficient chunks. According to HELP WRITESEQF, your command forces UniData to immediately write the data to the disk so you're taking an I/O hit. -2- Would this be easier? _HOLD_ is a DIR-type file, so you can just PRINT each data line you want. The data is then delimited by linefeeds (ASCII 10) at the Unix level. Unidata converts the linefeeds to attribute marks whenever you work with a DIR-type record from a Unidata command. There's an option in the SETPTR command to choose the output file name you want, but don't recall the exact syntax. Hope this helps, Tom [EMAIL PROTECTED] 10/20/06 11:04 AM I'm going to ask yet another dumb question - Unidata 6.1.4 on Solaris (soon to be 7.1.x). I'm selecting a bunch of records and then outputting data from them into an ascii file in _HOLD_. If I open a sequential file, write the data line-by-line (WRITESEQF) and close the file, it takes about 5 minutes. If I save the data in a @FM delimited record and then write the record out at the end, it takes about 3 seconds. snip - This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the LabCorp Privacy Officer at [EMAIL PROTECTED] or call (877) 23-HIPAA / (877) 234-4722. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Slow ascii output
Jeff, why WRITESEQF instead of WRITESEQ? You're completely undermining write buffering with WRITESEQF are you not? -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com ** Check out scheduled Connect! training courses at http://www.PrecisOnline.com/train.html. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Slow ascii output
In message [EMAIL PROTECTED], Jeffrey Butera [EMAIL PROTECTED] writes I'm going to ask yet another dumb question - Unidata 6.1.4 on Solaris (soon to be 7.1.x). I'm selecting a bunch of records and then outputting data from them into an ascii file in _HOLD_. If I open a sequential file, write the data line-by-line (WRITESEQF) and close the file, it takes about 5 minutes. If I save the data in a @FM delimited record and then write the record out at the end, it takes about 3 seconds. BE WARNED. We had exactly the same thing the other way round - indeed I rewrote a lot of our routines to use WRITESEQ instead of building an array in BASIC. I'm well aware that writing sequentially is doing a whole lot more disk I/O but I can't believe the difference in speed. Are their any subtleties other than disk I/O? I seem to recall some discussion about seq files and maintaining the pointer of where the current position in the file, but I'm foggy on these topics... Our system was short of RAM - 16 meg for 32 users (PI/Open on an EXL 7330). It thrashed enough under normal load, even before you started to try and build large (and I mean LARGE) strings in BASIC... Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Slow ascii output
I use writeseq. Yesterday I ran a process that selects a number of files, parses them into special formats, and writes them out. I created 65 files, 106 MB. Total time: 4 minutes. UD 5.1.27, Windows 2003 However, if you are writing to a dir file then you can use either a dynamic array or dimensioned (make sure you put something in each row or you will get an unassigned variable error) and simply write to the file. I find the writeseq faster. I use the best of both worlds and do: OPENSEQ 'dir type file', 'txt file' TO myfile ELSE STOP WRITESEQ line APPEND ON myfile ELSE STOP This way I don't have a hard-coded file path in my code and can simply move the file around by changing the VOC pointer. Hth Colin Alfke Calgary, Canada -Original Message- From: Jeffrey Butera I'm going to ask yet another dumb question - Unidata 6.1.4 on Solaris (soon to be 7.1.x). I'm selecting a bunch of records and then outputting data from them into an ascii file in _HOLD_. If I open a sequential file, write the data line-by-line (WRITESEQF) and close the file, it takes about 5 minutes. If I save the data in a @FM delimited record and then write the record out at the end, it takes about 3 seconds. I'm well aware that writing sequentially is doing a whole lot more disk I/O but I can't believe the difference in speed. Are their any subtleties other than disk I/O? I seem to recall some discussion about seq files and maintaining the pointer of where the current position in the file, but I'm foggy on these topics... -- Jeff Butera, Ph.D. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Slow ascii output
no one and I mean NO ONE uses a system with 16 MB ram today! we have 65 users on 2 gig ram, and when we do payments of unemployment salaries to our members we do everything in memory, and just write the edi file to a record a large batch takes less than two minutes and it also generates payment specifications for storage in pdf format (using cross pdf package). oh and we also do an xml conversion of the edi file on the fly aswell.. UniVerse is really a top performer when it comes to number crunching and file management how do you power a 16 meg system today ?? - with steam ? Med venlig hilsen Claus Derlien programmxr Edb-afdelingen Our system was short of RAM - 16 meg for 32 users (PI/Open on an EXL 7330). It thrashed enough under normal load, even before you started to try and build large (and I mean LARGE) strings in BASIC... Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
