| Time |
Nick |
Message |
| 00:02 |
bshum |
Oh that's odd |
| 00:03 |
bshum |
Why'd I think it was only 200000, the README clearly says 2000000 :( |
| 00:03 |
* bshum |
is having one of those nights |
| 00:03 |
bshum |
Nevermind then, all is right in the world, except that bshum can't read clearly anymore |
| 00:11 |
bshum |
I decided to just do a signoff branch instead of committing, better safer when someone else double-checks it again tomorrow. And maybe test it with Debian versions too. |
| 00:11 |
* bshum |
calls that a good night |
| 00:25 |
|
mceraso joined #evergreen |
| 02:27 |
|
gmcharlt_ joined #evergreen |
| 06:29 |
|
geoffsams joined #evergreen |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
agoben joined #evergreen |
| 07:38 |
|
kmlussier joined #evergreen |
| 07:40 |
kmlussier |
rhamby++ # Mac client |
| 07:57 |
|
krvmga joined #evergreen |
| 08:03 |
kmlussier |
bshum: Yeah, we noticed the modperl issue last week when my VM builds starting failing. |
| 08:08 |
csharp |
@blame mod_perl |
| 08:08 |
pinesol_green |
csharp: It's all mod_perl's fault! |
| 08:13 |
kmlussier |
Good morning csharp! |
| 08:16 |
bshum |
kmlussier: Well that's special. |
| 08:17 |
bshum |
Might have to make a separate branch for rel_2_4 OpenSRF for that then. Till we move all those bits to Evergreen side anyways per gmcharlt's wishlist to change |
| 08:34 |
|
Dyrcona joined #evergreen |
| 08:40 |
* Dyrcona |
starts the process of building four vms. |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:49 |
jeff |
does it go something like this? ansible-playbook -i util/ec2.py util/provision-ec2-eg-dr.yml |
| 08:50 |
Dyrcona |
jeff: :P |
| 08:50 |
Dyrcona |
of course it doesn't.... |
| 08:50 |
Dyrcona |
It goes like this ./buildvm.sh |
| 08:51 |
jeff |
automation is automation, and automation is good. :-) |
| 08:52 |
Dyrcona |
Yep. |
| 08:54 |
kmlussier |
@quote random |
| 08:54 |
pinesol_green |
kmlussier: Quote #109: "< kmlussier> I live for sanity checks." (added by csharp at 10:06 AM, April 08, 2015) |
| 08:54 |
Dyrcona |
I am reminded of an excerpt from the book Practical Common Lisp: http://www.gigamonkeys.com/book/macros-defining-your-own.html#the-story-of-mac-a-just-so-story |
| 08:54 |
Dyrcona |
@quote random |
| 08:54 |
pinesol_green |
Dyrcona: Quote #18: "Alan McKay: Like the ski resort of girls looking for husbands and husbands looking for girls, the situation is not as symmetrical as it might seem." (added by Dyrcona at 11:51 AM, November 10, 2011) |
| 08:54 |
Dyrcona |
hah. Not from the channel, but I like it. :) |
| 08:59 |
|
mrpeters joined #evergreen |
| 09:06 |
|
mmorgan joined #evergreen |
| 09:17 |
|
bos20k joined #evergreen |
| 09:20 |
|
yboston joined #evergreen |
| 09:26 |
|
afterl joined #evergreen |
| 09:41 |
Dyrcona |
@blame ubuntu |
| 09:41 |
pinesol_green |
Dyrcona: ubuntu caused the white screen of death! |
| 09:42 |
Dyrcona |
Don't think I should be seeing this while installing prerequisites: grep: /etc/apache2/httpd.conf: No such file or directory |
| 09:42 |
bshum |
They probably did... those jerks. |
| 09:43 |
csharp |
Dyrcona: that's from running the EG Makefile.install for xenial? |
| 09:44 |
Dyrcona |
csharp: Nope, OpenSRF/src/extras/Makefile.install ubuntu-trusty |
| 09:45 |
Dyrcona |
And, I only started the trusty VMs, so.... |
| 09:45 |
csharp |
hmm |
| 09:45 |
tsbere |
I think they have been working to switch from httpd.conf to apache2.conf for a while, maybe they finally stopped putting httpd.conf in by default? |
| 09:45 |
Dyrcona |
Maybe. |
| 09:45 |
csharp |
if so, that's a crappy thing to do in an LTS |
| 09:45 |
* Dyrcona |
echoes csharp |
| 09:46 |
tsbere |
More specifically, I don't think it has been *read* by default for a while, so... |
| 09:46 |
Dyrcona |
apache2.conf and httpd.conf are bother there. |
| 09:46 |
Dyrcona |
s/bother/both/ |
| 09:46 |
Dyrcona |
"Oh, bother," said Pooh. |
| 09:47 |
tsbere |
Ok, that is a very different question. Mainly "why can't grep see httpd.conf then?" |
| 09:47 |
Dyrcona |
Maybe it wasn't there when the grep ran? |
| 09:47 |
Dyrcona |
It was possibly installed after. |
| 09:47 |
Dyrcona |
I am root or I would not have made it that far. :) |
| 09:48 |
Dyrcona |
Looking at what it was doing, it may not be important. |
| 09:48 |
Dyrcona |
I'm building on a concerto vm so I can test one of my own patches real quick. |
| 09:49 |
Dyrcona |
I was going to test berick's angular fixes a bit later. |
| 09:51 |
Dyrcona |
I'll probably just use concerto today, since I don't feel like waiting on reingests, etc. on a copy of production. |
| 09:53 |
Dyrcona |
bshum: You're right about trusty not activating mod_perl any more. |
| 09:54 |
|
mmorgan joined #evergreen |
| 09:55 |
Dyrcona |
Well, opensrf and opensrf.math add work. |
| 09:55 |
Dyrcona |
Now to install and test Evergreen. |
| 10:00 |
|
berick joined #evergreen |
| 10:04 |
|
afterl left #evergreen |
| 10:06 |
|
bos20k_ joined #evergreen |
| 10:06 |
|
jvwoolf joined #evergreen |
| 10:16 |
* jeff |
shakes fist at search path |
| 10:18 |
Dyrcona |
On the plus side, I'll be pushing a working branch for LP 1548993 shortly. |
| 10:18 |
pinesol_green |
Launchpad bug 1548993 in Evergreen 2.9 "TPAC Show More/Fewer Details Button does not work with show_more_details.default set to true" [Undecided,Confirmed] https://launchpad.net/bugs/1548993 |
| 10:24 |
jeff |
mumble grumble functions with hardcoded references to schemas that no longer exist... |
| 10:26 |
Dyrcona |
Or maybe not so shortly.... |
| 10:29 |
|
mmorgan1 joined #evergreen |
| 10:30 |
tsbere |
jeff: I feel your pain. Though I wonder if these are custom functions or not. |
| 10:47 |
csharp |
@decide I am root or I AM GROOT |
| 10:47 |
pinesol_green |
csharp: go with I am root |
| 10:49 |
tsbere |
@decide Blame Vendors or Blame Users |
| 10:49 |
pinesol_green |
tsbere: go with Blame Vendors |
| 10:51 |
Dyrcona |
Or maybe about a couple of minutes ago... ;) |
| 11:03 |
jeff |
tsbere: non-custom afaik, but likely mangled over time by weird search path issues and numerous migrations. |
| 11:26 |
|
bmills joined #evergreen |
| 11:30 |
kmlussier |
@dessert |
| 11:30 |
* pinesol_green |
grabs some Key Lime Pie for kmlussier |
| 11:30 |
kmlussier |
pinesol_green: That's not what I had in mind. |
| 11:30 |
pinesol_green |
kmlussier: Have you tried throwing it across the room? |
| 11:30 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 11:39 |
|
Stompro joined #evergreen |
| 11:45 |
kmlussier |
@marc 263 |
| 11:45 |
pinesol_green |
kmlussier: The projected date of publication used in bibliographic records for works that have not yet been published. [] |
| 11:48 |
|
bmills joined #evergreen |
| 11:49 |
|
bmills1 joined #evergreen |
| 12:07 |
|
brahmina joined #evergreen |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:28 |
|
mmorgan joined #evergreen |
| 12:32 |
|
bmills joined #evergreen |
| 12:55 |
|
mtcarlson left #evergreen |
| 13:00 |
|
krvmga joined #evergreen |
| 13:29 |
* jeff |
reads pingest.pl to determine if --skip-browse --skip-search --skip-facets is essentially a attrs-only reingest |
| 13:31 |
jeff |
looks like "yes" |
| 13:33 |
Dyrcona |
It is. |
| 14:04 |
kmlussier |
So, for the purposes of posting the fix to the lp957466_update_date_and_source.pg test, should I re-open bug 1447746, which broke the test, or should I open a new bug? |
| 14:04 |
pinesol_green |
Launchpad bug 1447746 in Evergreen "Do not update bib source on match-only merge" [Wishlist,Fix committed] https://launchpad.net/bugs/1447746 |
| 14:09 |
* kmlussier |
decides to re-open the old bug. |
| 14:09 |
Dyrcona |
kmlussier: bshum has been reopening old bugs for such things. I tend to open a new bug. |
| 14:09 |
Dyrcona |
Reopening the old bug seems fine to me. |
| 14:10 |
Stompro |
bmills++ ; pointing out the series facet fix presented at the conference to me. |
| 14:15 |
Stompro |
miker++ for the Metadata Abattoir presentation, thanks. |
| 14:27 |
jeff |
Dyrcona: thanks for the confirmation. :-) |
| 14:30 |
Dyrcona |
Well, looks my xenial vms don't really work. |
| 14:30 |
Dyrcona |
Not sure what's causing the breakage beyond network interface names changing, but all kinds of thing seem wrong with them. |
| 14:31 |
berick |
built my first functioning xenial image for the first time yesterday |
| 14:32 |
berick |
only issue I had was (once again) requiring the use of apache2ctl-websockets to stop/start websockets. init/service scripts no likey |
| 14:32 |
berick |
probably something that could be fixed w/ a small amount of effort |
| 14:36 |
Dyrcona |
berick: how are you building your images? I'm using python vmbuilder, and I think this is a recent issue. |
| 14:37 |
berick |
Dyrcona: virt-manager |
| 14:38 |
Dyrcona |
berick: You're using an ISO? |
| 14:38 |
* jeff |
gives up on a record attr ingest after only 3 hours, opts to give pingest a try |
| 14:38 |
berick |
Dyrcona: yeah, 16.04 server ISO as of yesterday |
| 14:39 |
Dyrcona |
jeff: pingest will still probably take longer than 3 hours. |
| 14:40 |
Dyrcona |
berick: It was working for me when I built from an ISO with virt-install and then use virt-viewer or virt-manager to finish the installation. |
| 14:41 |
Dyrcona |
berick: I also think it was working with python vmbuilder when I last built on in late April. |
| 14:41 |
* berick |
nods |
| 14:46 |
Dyrcona |
eg_db_config also hangs on me. |
| 14:47 |
Dyrcona |
And, I'm not creating the database or loading data. |
| 14:47 |
Dyrcona |
Just --update-config --service-all --create-offline and the options for the database user, host, port, and database. |
| 14:48 |
Dyrcona |
Ah, crazy.... |
| 14:48 |
Dyrcona |
It works by hand, but not from a shell script... |
| 14:48 |
jeff |
broken name resolution? |
| 14:48 |
jeff |
hrm. |
| 14:49 |
berick |
hm, yeah, double check /etc/hosts |
| 14:50 |
berick |
for private.localhost / public.localhost |
| 14:50 |
Dyrcona |
That's all set up. |
| 14:50 |
Dyrcona |
The execscript seemed to work. |
| 14:51 |
Dyrcona |
As I mentioned earlier, I had to change the network config to ens3 from eth0. |
| 14:51 |
Dyrcona |
Starting services, all seems well. |
| 14:54 |
Dyrcona |
It seems to work. I can log in with the web staff client and look up patrons. |
| 14:55 |
Dyrcona |
And, that was all I really wanted to do. |
| 14:55 |
* Dyrcona |
was testing berick's angular fix on trusty and on xenial. |
| 14:56 |
Dyrcona |
I asked in #ubuntu-virt, but I don't expect any answers. |
| 14:56 |
* Dyrcona |
always has the special problems. |
| 15:00 |
* Dyrcona |
is going to push the fixes to master. They work AFAICT. |
| 15:03 |
jeff |
i suppose if i'm this impatient i should be benchmarking in smaller batches than "everything" |
| 15:03 |
berick |
Dyrcona++ |
| 15:05 |
pinesol_green |
[evergreen|Bill Erickson] LP#1554714 Ang. 2.5 hotkeys plugin update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3e61494> |
| 15:05 |
pinesol_green |
[evergreen|Bill Erickson] LP#1554714 Add explicit phantomjs-prebuilt dependency - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2f024d4> |
| 15:09 |
jeff |
berick++ Dyrcona++ |
| 15:09 |
berick |
bshum++ |
| 15:10 |
jeff |
i (mostly idly) wonder why our config.metabib_field def for Genre (id=33) was indexing 659 in addition to 655 |
| 15:10 |
jeff |
we have two records with 659 tags. |
| 15:11 |
jeff |
(659 is not defined) |
| 15:14 |
kmlussier |
jeff: It seems like I asked that question at one point, either on the bug or IRC. I can't recall the answer now. |
| 15:15 |
jeff |
oh, i thought it was purely a local quirk! |
| 15:15 |
jeff |
i hadn't even bothered to troll through git history. |
| 15:15 |
kmlussier |
jeff: Oh, is that a local index? Maybe I'm thinking of something else then |
| 15:15 |
kmlussier |
jeff: https://bugs.launchpad.net/evergreen/+bug/1067823/comments/10 |
| 15:15 |
pinesol_green |
Launchpad bug 1067823 in Evergreen "tpac: genre links in record details page launch subject search" [Medium,Fix released] |
| 15:16 |
jeff |
well, we had defined it at some point in the past, but the upgrade scripts from 2.7.4 to 2.10 define it fresh, and the only difference between that and what we already had was our xpath included 659. |
| 15:16 |
* jeff |
looks at the bug |
| 15:16 |
jeff |
istr we backported the index def, so we probably did that before the change noted in that bug. |
| 15:17 |
kmlussier |
jeff: Before the index was created in master, the OPAC display of the genre fields had always included the 659, IIRC |
| 15:17 |
kmlussier |
So if you were basing your index on what was used in the display, I can see why you would have included the 659 |
| 15:18 |
kmlussier |
Always, being as far back as we had the tpac. I don't know what we did in jspac |
| 15:32 |
|
jvwoolf1 joined #evergreen |
| 15:38 |
|
Christineb joined #evergreen |
| 16:00 |
kmlussier |
@dessert |
| 16:00 |
* pinesol_green |
grabs some Pumpkin Pie for kmlussier |
| 16:03 |
* bshum |
likes pumpkin pie. |
| 16:04 |
bshum |
berick++ Dyrcona++ # yay for the return of working webstaff! |
| 16:05 |
Dyrcona |
bshum++ berick++ |
| 16:05 |
Dyrcona |
@dessert |
| 16:05 |
* pinesol_green |
grabs some Krispy Kreme Donuts for Dyrcona |
| 16:06 |
bshum |
Now if we can test and merge kmlussier's fix for the pgtap tests then maybe we'll get a live test success again! |
| 16:06 |
bshum |
Weekend project, whee! |
| 16:07 |
kmlussier |
I like pumpkin pie too, but I've mostly been looking for chocolate today. |
| 16:08 |
kmlussier |
pinesol_green has been holding out on me. |
| 16:08 |
pinesol_green |
kmlussier: What do you mean? An African or European swallow? |
| 16:08 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 16:12 |
berick |
@eightball is pinesol_green a bot? |
| 16:12 |
pinesol_green |
berick: _I_ don't know. |
| 16:12 |
bshum |
Spooky..... |
| 16:13 |
berick |
pinesol_green just passed the Turing test |
| 16:13 |
pinesol_green |
berick: Thank you berick! But our princess is in another castle! |
| 16:13 |
pinesol_green |
berick: I am only a bot, please don't think I'm intelligent :) |
| 16:17 |
csharp |
@blame [quote random] |
| 16:17 |
pinesol_green |
csharp: Quote #57: "< jeff_> nine million useless rows in money.billing, nine million useless rows... take one down, pass it around, eight million nine-hundred and ninety-nine thousand nine-hundred and ninety nine useless rows in money.billing..." (added by csharp at 03:15 PM, May 23, 2013) wants the TRUTH?! Quote #57: "< jeff_> nine million useless rows in money.billing, nine million useless rows... (1 more message) |
| 16:17 |
csharp |
@more |
| 16:17 |
pinesol_green |
csharp: take one down, pass it around, eight million nine-hundred and ninety-nine thousand nine-hundred and ninety nine useless rows in money.billing..." (added by csharp at 03:15 PM, May 23, 2013) CAN'T HANDLE THE TRUTH!! |
| 16:19 |
Dyrcona |
@quote random |
| 16:19 |
pinesol_green |
Dyrcona: Quote #135: "<Dyrcona> ASCII stupid question; get a stupid ANSI. :)" (added by kmlussier at 09:41 AM, December 22, 2015) |
| 16:20 |
kmlussier |
I added that quote? huh |
| 16:23 |
jeff |
Oh hey! Those nine million useless rows are dead now. That's happy. :-) |
| 16:25 |
Dyrcona |
jeff++ |
| 16:30 |
berick |
speaking of big deletes, I'm looking forward to deleting 260M rows from usr_activity soon and making it all transient. |
| 16:31 |
berick |
and by deleting, i mean truncating the table, after saving a tiny fraction of the data |
| 16:32 |
berick |
having a load balancer log in to 3 different sip machines once per second each (to confirm they are responding) really blows up the activity table, yeesh |
| 16:32 |
jeff |
heh. |
| 16:33 |
jeff |
i think the most frequent automated SIP login we have is every 5 mins. |
| 16:34 |
jeff |
so, sounds like we'd have about 900 times fewer rows in said table :-) |
| 16:35 |
jeff |
okay, 288 minutes is more than i'm willing to let this run for today. time to kill and do some more benchmarking on smaller batches. |
| 16:36 |
jeff |
i suspect i'll benefit from tuning some postgres options AND from pingest. |
| 16:38 |
jeff |
oh, wait. |
| 16:38 |
jeff |
ah, okay. for a half moment i thought it had just finished. :-) |
| 16:52 |
jeff |
yeah, tuning required. |
| 16:53 |
jeff |
373.918 ms vs 4704.191 ms for ... ten records. |
| 16:53 |
jeff |
(which is almost too small a sample for reasonable benchmarking) |
| 17:16 |
|
mmorgan left #evergreen |
| 17:18 |
jeff |
well nuts. one of these things is not like the other. |
| 17:22 |
jeff |
YMMV (YDBMV?), but metabib.reingest_record_attributes between 2.7 and 2.10 appears to be ~12x slower |
| 17:24 |
jeff |
a big part of that might be the new rows in config.marc21_ff_pos_map. |
| 17:32 |
jeff |
and config.coded_value_map |
| 17:35 |
|
bmills joined #evergreen |
| 17:52 |
dbwells |
jeff: Our initial ingest after the 2.9 upgrade in December was nice and fast. Recent partial re-ingest (still on 2.9) was dramatically slower. Haven't had time to look into it any further, but glad to think we might not be alone. |
| 17:54 |
jeff |
dbwells: any point release upgrades between those two ingests? |
| 17:55 |
jeff |
dbwells: and what kind of partial re-ingest were you dealing with? |
| 17:56 |
dbwells |
jeff: I don't think so for point upgrades. More likely a point upgrade for Postgres than for EG, if anything. |
| 17:58 |
dbwells |
jeff: It was just a full reingest of a few hundred records, but slow enough to notice. I've really just been ignoring it and hoping my testing was off that day for some other reason. |
| 17:59 |
jeff |
heh |
| 18:00 |
jeff |
it looks like with the help of pingest i can do a record-attrs-only ingest of ~400k records in 6 hours (16 pingest children) |
| 18:00 |
jeff |
extrapolating from 2000 records in 100 record batches with 4 and 16 children. |
| 18:00 |
jeff |
4m2.880s with 4 children |
| 18:01 |
jeff |
1m48.872s with 16 children |
| 18:02 |
jeff |
(for 2000 bibs) |
| 18:08 |
dbwells |
jeff: At 6pm on Friday, you may also find yourself in figure-out-later land :) Have a good weekend! |
| 18:11 |
jeff |
dbwells: you too! |
| 18:12 |
jeff |
dbwells: I don't know what might explain what you encountered in 2.9, but I suspect the speed difference I'm seeing is mostly due to the additions that 0967 makes to config.marc21_ff_pos_map, config.record_attr_definition, config.coded_value_map, and config.composite_attr_entry_definition |
| 18:14 |
jeff |
as part of bug 1371647 |
| 18:14 |
pinesol_green |
Launchpad bug 1371647 in Evergreen "config.marc21_ff_pos_map needs an audit" [Wishlist,Fix released] https://launchpad.net/bugs/1371647 |
| 18:16 |
dbwells |
I am perfectly willing to believe my testing was a fluke of some kind, though not looking forward to things getting even slower, if that's the case. |
| 18:21 |
jeff |
those four tables gained: |
| 18:21 |
jeff |
128, 782, 2610, and 105 rows |
| 18:22 |
jeff |
so yeah, I think it's reasonable to expect that to impact speed of ingest. |
| 18:56 |
jeff |
are TADL and Sitka the first to take the 2.10 plunge? |
| 19:44 |
jeffdavis |
I should take a look at pingest.pl, I'm accustomed to doing reingests more or less manually |
| 19:47 |
jeffdavis |
I've been seeing ~48hrs for a record attribute reingest of 1.8M records with 6 parallel processes in 2.10, but that's not really an apples-to-apples comparison with pingest.pl |
| 19:58 |
jeff |
I'm currently doing an attribute-only reingest using pingest: pingest.pl --skip-browse --skip-search --skip-facets --max-child 28 |
| 19:59 |
jeff |
it might not be that far off from how you're doing things in parallel. |
| 20:03 |
jeffdavis |
(1) psql -c 'SELECT id FROM biblio.record_entry WHERE NOT deleted' -o id-list.txt |
| 20:03 |
jeffdavis |
(2) split -d -n l/6 id-list.txt reingest.sql. |
| 20:04 |
jeffdavis |
(3) open 6 screen windows, connect to the db, and run reingest.sql.XX separately in each |
| 20:05 |
jeffdavis |
er (2.5) `sed -i 's/^\(.*\)$/SELECT metabib.reingest_record_attributes(\1);/' reingest.sql.*` |
| 20:06 |
jeffdavis |
so I guess effectively the same, but much more cumbersome my way :) |
| 20:08 |
jeff |
i think pretty close, yep. :-) |
| 20:09 |
jeff |
pingest uses a slightly different query, but any differences in speed are probably small. |
| 20:10 |
jeff |
for the record attrs: SELECT metabib.reingest_record_attributes(id, NULL::TEXT[], marc) FROM biblio.record_entry WHERE id = ? |
| 20:10 |
jeff |
where the ? is a placeholder that gets a list of (by default) 10,000 bre ids. |
| 20:11 |
jeff |
oh, actually no. it runs one query per record id. |
| 20:11 |
jeff |
i misread. |
| 20:15 |
jeff |
jeffdavis: are you aware of any other systems that have upgraded to 2.10 yet? |
| 20:16 |
jeff |
jeffdavis: looks like Sitka and TADL are both upgrading this weekend, and beyond that I'm not sure if anyone else has gone before or has published a schedule. |
| 20:16 |
jeff |
(I didn't spend a LOT of time looking.) |
| 20:18 |
|
jeffdavis1 joined #evergreen |
| 20:18 |
jeffdavis1 |
bah, irc problems :( |
| 20:18 |
jeff |
doh. |
| 20:18 |
jeffdavis1 |
jeff: I'm not aware of anyone else on 2.10 yet |
| 20:18 |
jeffdavis1 |
although I could easily have missed someone |
| 20:18 |
jeff |
Apparently I was overly optimistic about someone else having already gone first by now when I picked this date back in March or April. :-) |
| 20:18 |
jeffdavis1 |
fwiw things have gone really smoothly in our testing, so I'm cautiously optimistic |
| 20:19 |
jeff |
excellent. |
| 20:20 |
jeffdavis1 |
you're on PG 9.4 as well, right? |
| 20:20 |
jeff |
correct. |
| 20:22 |
jeff |
Is your upgrade window duration mostly to ensure that you have enough time for the ingest to fully complete before the system's back under production load, or are you anticipating other bits to take a lot of time also? |
| 20:22 |
jeff |
(or rolling other things into the downtime, like hardware upgrades/etc) |
| 20:25 |
jeffdavis1 |
it's mostly to give time for testing before we go live |
| 20:25 |
jeff |
got it. |
| 20:26 |
jeff |
multiple reasons for asking: curiosity / comparing notes, as we're upgrading this weekend also |
| 20:26 |
jeff |
but also, i'm thinking about ways overall to make upgrades less painful. |
| 20:27 |
jeffdavis1 |
I actually think a 24 hour window would have been more than enough for us this year, but it was scheduled before we had a good sense of what was going to be involved |
| 20:27 |
jeffdavis1 |
and most of our libraries are closed on mondays anyways |
| 20:27 |
jeff |
ah. |
| 20:28 |
jeff |
yeah, saturday nights are good for us to start -- last libraries close at 6 PM, then we have 18 hours until the next open time (noon sunday) |
| 20:29 |
jeff |
that's a single location, but our largest. good chance if things go wrong we'll notice. |
| 20:29 |
jeff |
then there's another 5pm - 9am close time and we have a handful of libraries open monday, then on tuesday everyone's open. |
| 20:31 |
jeff |
we put patron auth for most electronic resources in offline mode while we're down, maintenance pages up for the catalog (need to work on some better options for the mobile apps), and then bring things back online when we're ready. |
| 20:32 |
jeffdavis1 |
yup, same process here |
| 20:33 |
jeffdavis1 |
I'm hoping things go well enough that we are ready to go live on Monday with the smaller number of libraries, although part of the issue there is having support staff on hand to answer calls/issues if anyone reports issues |
| 20:33 |
* jeff |
nods |
| 20:33 |
jeffdavis1 |
oh, it's also a long weekend in Canada this weekend, not sure if that's the case for you folks |
| 20:34 |
jeff |
ah, nope. that's next weekend for us. |
| 20:35 |
jeff |
The last Monday in May is Memorial Day. |
| 20:36 |
jeffdavis1 |
ah right |
| 20:37 |
* jeff |
ponders crazy things like pre-computed re-ingests |
| 20:38 |
jeff |
if you re-ingest beforehand on a snapshot of production, then dump the tables in question, you could truncate-and-copy in production after the upgrade, then reingest just those bibs that have been modified since your snapshot... |
| 20:38 |
jeff |
you'd need to adjust sequences and such... |
| 20:39 |
jeff |
but i don't think you'd run into major foreign key issues... |
| 20:43 |
jeff |
probably a few options to try with the indexes on the tables. |
| 20:44 |
jeff |
but overall i suspect that you might save a bit of time. |
| 20:44 |
jeff |
(or, spend the time beforehand) |
| 20:44 |
jeff |
to be a little more precise. |
| 20:49 |
jeff |
might only be worth the effort on a sitka or pines or indiana scale. |
| 20:54 |
jeffdavis1 |
an idea worth exploring for sure |
| 22:40 |
jeff |
pingest winding down... |
| 22:51 |
jeff |
oh, interesting. the default batch size was probably too large for my situation. |
| 22:51 |
jeff |
because now it's down to 11 batches and therefore only using 11 cores. |
| 22:52 |
jeff |
but at 10,000 records per batch, that's about... 83 minutes left. |
| 22:54 |
jeff |
(at half power or so) |
| 23:05 |
|
Stompro joined #evergreen |
| 23:06 |
|
gsams joined #evergreen |
