| Time |
Nick |
Message |
| 02:28 |
|
eady joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 08:10 |
|
collum joined #evergreen |
| 08:32 |
|
mantis joined #evergreen |
| 08:32 |
|
Dyrcona joined #evergreen |
| 08:33 |
|
mantis joined #evergreen |
| 08:38 |
|
dguarrac joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 09:20 |
Dyrcona |
So, I configured Pg 9.6 the same as I had configured Pg10 the other day, but 9.6 does not appear to be using as much memory as Pg 10 did. With Pg10 there were 10s of GB of cache used. With 9.6 it's at 19GB. |
| 09:23 |
Dyrcona |
Unfortunately, I didn't write it down. |
| 09:25 |
Dyrcona |
I guess my timing numbers are meaningless at this point with the busted array. |
| 09:33 |
|
mmorgan left #evergreen |
| 09:35 |
|
mmorgan joined #evergreen |
| 09:42 |
mmorgan |
For a workstation using Hatch, is there a way to force the printer dialog? Staff want to have the option to choose a different printer for the pull list. |
| 09:45 |
JBoyer |
Dyrcona, so long as the array is messed up for all of them it should still a valid test. You're comparing the versions relative to each other, not to a similar box with a working array. |
| 10:01 |
|
jvwoolf joined #evergreen |
| 10:05 |
Dyrcona |
JBoyer: True, but I'd like to fix it. We're going to see if we have a drive we can swap in, soon. Failing that I have a couple of old database servers that I might be able to use, but they don't have enough space to hold multiple copies of our database. |
| 10:06 |
JBoyer |
Oh, sure; I don't mean you shouldn't look into it, just that the current work isn't wasted. Comparing things across the line where it's fixed is no good, but that's different. |
| 10:07 |
Dyrcona |
Yeah, I suppose. So, far, it looks like 9.6 is slower than 10, but I am not that interested in 9.6. |
| 10:08 |
Dyrcona |
I'm just running the db upgrade and then the "Did you mean" set up steps at this point. |
| 10:08 |
JBoyer |
I'm mostly interested in 13. The way I see it there's no point in staying on 10, 11, or 12 as long as we have 9.6 (we can't anyway with the versioning change, but you know what I mean) so the Big Deal is making sure the latest release works as well as the old one. |
| 10:09 |
JBoyer |
Not trying to change your method, but worst case to me would be something like "11 is faster than 9.6, everything else is slower and will take a long time to untangle." |
| 10:09 |
JBoyer |
Fortunately that's also highly unlikely, heh. |
| 10:10 |
Dyrcona |
Yeah. I was considering skipping 11 entirely. I've been doing quite a bit with 12 because I put it on port 5432 for almost a year. |
| 10:10 |
Dyrcona |
Fourteen should be out in October. |
| 10:11 |
berick |
when is 9.6 EOL? |
| 10:13 |
|
Dyrcona left #evergreen |
| 10:14 |
|
Dyrcona joined #evergreen |
| 10:14 |
Dyrcona |
Dang it. Wrong shortcut key.... |
| 10:14 |
Dyrcona |
berick: 9.6 is EOL this November. |
| 10:14 |
berick |
ugh |
| 10:14 |
Dyrcona |
10 is EOL November 2022. |
| 10:15 |
Dyrcona |
I hope to upgrade production here to Pg 10 in October. We've been running on training for a few months. |
| 10:15 |
Dyrcona |
Actually, I was searching for an email from John here at CW MARS about something that was slower in the staff client when we briefly ran training on Pg 12, but I haven't found it, yet. |
| 10:17 |
Dyrcona |
Overall performance of 10 and 9.6 is similar from my experience, but I don't have any numbers to back it up. |
| 10:18 |
Dyrcona |
Some things are faster on newer releases, well most things, but some things are slower, updating records with located URIs for example. |
| 10:18 |
Dyrcona |
I get much better performance on un-optimized Pg 9.6 with that than I do on optimized Pg 12, for instance. |
| 10:22 |
berick |
Dyrcona: your last comment, you mean accross the board or w/ specific work flows? |
| 10:23 |
Dyrcona |
With updating records with located URIs only. |
| 10:23 |
* berick |
nods |
| 10:24 |
berick |
other than verifying performance, are there any lingering blockers with upgrading? |
| 10:24 |
Dyrcona |
Updating Jackie Chan's authority record was an order of magnitude faster on Pg 12 because of the parallel workers. |
| 10:24 |
berick |
to, say, 13? |
| 10:25 |
Dyrcona |
I haven't exercised 13 as much as 12, but if you're on a relatively recent schema, then there aren't blockers other than performance going to 12 that I am aware of. Everything seems to work. |
| 10:25 |
berick |
cool, thanks |
| 10:25 |
berick |
may just start pushing my dev VM's to 13 just cuz |
| 10:26 |
Dyrcona |
I've been using 12 with my test/development VMs at CW MARS. I just decided to switch port 5432 to Pg 10 last week in preparation for going to Pg 10 in production. |
| 10:29 |
Dyrcona |
On my generic VMs, where I install concerto data and run the DB locally, I've been installing Pg10. |
| 10:29 |
JBoyer |
I do have a few demo / concerto machines on 12/13 so there shouldn't be anything major, but there are a few things that never really get tested on those. (perf among them) |
| 10:31 |
Dyrcona |
We load 10,000+ batches of electronic resource records from time to time, and I have a Perl script for that which can output timing data with a command line switch. |
| 10:32 |
Dyrcona |
I'll run that on the test server with a batch occasionally. It will take a couple of seconds to update most records on Pg 9.6. On Pg 12 it's typically 5 to 10 seconds, with some records going over 20 to 30 seconds. |
| 10:32 |
Dyrcona |
A batch of 10,000 can take hours on Pg 9.6 and days on Pg 12. |
| 10:33 |
berick |
Dyrcona: and that's still located URI-related? |
| 10:33 |
Dyrcona |
I want to profile that with plprofiler. It will hopefully show where the slowness comes from. |
| 10:33 |
Dyrcona |
Yeah, located URI related. |
| 10:34 |
Dyrcona |
I suspect it's the function to maintain the call number links that is slowing things down, but I don't know for sure. |
| 10:43 |
Dyrcona |
Hmm. Maybe a branch to add prerequisites for Pg 11 through 13 would be in order? I usually just install them manually. |
| 11:10 |
mmorgan |
Dyrcona: berick: We also load thousands of electronic resource records with located uris and it takes many hours. Dyrcona, we've likely had this conversation before, but would you mind sharing your script? |
| 11:11 |
* mmorgan |
was just having a discussion with colleagues yesterday about how time consuming loading the records is. |
| 11:13 |
mmorgan |
Incidentally, we have been running the fix in bug 1482757 in production for quite some time, but loading is still very slow. |
| 11:14 |
pinesol |
Launchpad bug 1482757 in Evergreen 3.5 "Loading records with located URIs should not delete and recreate call_numbers" [Low,Confirmed] https://launchpad.net/bugs/1482757 |
| 11:17 |
|
jvwoolf1 joined #evergreen |
| 11:25 |
Dyrcona |
mmorgan: I saw no change in performance with the patch from that bug. It does declutter the database a bit. |
| 11:26 |
mmorgan |
More than a bit in our case :) |
| 11:26 |
Dyrcona |
:) |
| 11:27 |
Dyrcona |
I'll see about sharing that script. It may rely on some custom tables and views for mapping vendors with URLs. I know my script to remove URLs relies on those tables. |
| 11:29 |
mmorgan |
Dyrcona: Thanks! Do you find removing URLs to be extremely slow also? |
| 11:45 |
Dyrcona |
mmorgan: I don't do that as often. |
| 11:45 |
Dyrcona |
TBH, I don't get asked to mess with records very often. I think the cataloging staff like doing it themselves in small batches. |
| 11:46 |
* mmorgan |
nods |
| 11:48 |
Dyrcona |
mmorgan: I shared the script previously. I have made some changes since then, so I just edited it on pastebin: https://pastebin.com/g4RGDJLr |
| 11:49 |
mmorgan |
My colleague has always loaded the electronic records via the client in small batches, but it's not practical for the volume we do. |
| 11:49 |
mmorgan |
Dyrcona++ |
| 11:49 |
mmorgan |
Thanks, we'll take a look! |
| 11:50 |
|
jvwoolf1 joined #evergreen |
| 12:34 |
|
collum joined #evergreen |
| 12:55 |
|
collum joined #evergreen |
| 13:21 |
|
collum joined #evergreen |
| 13:23 |
mmorgan |
Any thoughts on forcing the printer dialog box to come up when printing the pull list? Thought I remembered an option or sticky setting to do that, but can't find any such option. The only workaround I've come up with is to disable Hatch, print the list, then re-enable. |
| 13:25 |
berick |
mmorgan: the Hatch API does support an option to force the (Java) print dialog to open, but I don't think we're really using it at this point. |
| 13:27 |
berick |
well, except in the printer settings UI where you can 'print with dialog' |
| 13:29 |
mmorgan |
berick: That's what I was looking for! I don't see it in printer settings, though. |
| 13:30 |
|
jvwoolf joined #evergreen |
| 13:33 |
berick |
mmorgan: it's under the Test Printing tab |
| 13:33 |
berick |
so, it's only there for testing |
| 13:34 |
berick |
if you test it, beware the dialog does not always (ever?) steal focus, so it sits open behind the browser window. |
| 13:35 |
berick |
i could imagine having a way to specify "print via browser" for certain print contexts / templates |
| 13:41 |
mmorgan |
Oh, ok. At least I know I didn't imagine it ;-). They are looking for a way to redirect to another printer when their main one has an issue. Likely not something that will happen that often. I will offer them the option of disabling hatch momentarily when that's necessary. |
| 13:41 |
mmorgan |
berick++ |
| 13:43 |
berick |
gotach. it's also a pretty quick change to tell Hatch to use a different printer |
| 13:44 |
berick |
heh, gotach |
| 15:40 |
|
jvwoolf joined #evergreen |
| 15:55 |
|
finnx joined #evergreen |
| 16:34 |
|
jvwoolf1 joined #evergreen |
| 16:58 |
|
jvwoolf1 left #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
