Evergreen ILS Website

IRC log for #evergreen, 2020-09-02

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
01:03 dbwells joined #evergreen
02:02 laurie_ joined #evergreen
06:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:56 agoben joined #evergreen
07:20 rjackson_isl_hom joined #evergreen
07:59 collum joined #evergreen
08:07 alynn26 joined #evergreen
08:22 Dyrcona joined #evergreen
08:33 dbwells joined #evergreen
08:37 mantis1 joined #evergreen
08:39 mmorgan joined #evergreen
08:41 alynn26_away joined #evergreen
08:42 mmorgan1 joined #evergreen
08:43 jeff Hrm. Searching for a patron by email address seems incredibly slow this morning. I wonder if it's related to enabling opt in last night.
08:53 jeff ("incredibly slow" in this case is ~60 seconds)
09:00 * mmorgan has always found searching by email slow, though not *that* slow. What opt-in did you enable?
09:06 rfrasur joined #evergreen
09:10 jeff bad plan. looks much improved with a VACUUM ANALYZE on actor.usr and actor.usr_org_unit_opt_in tables.
09:10 jeff I think the speed only went south when I created a single row in actor.usr_org_unit_opt_in.
09:16 * csharp reads "opt in" and imagines checkbox labeled "click here for slower search times!"
09:16 jeff mmorgan: I set opensrf/default/share/user/opt_in to true in opensrf.xml, and then configured related OU settings.
09:17 * mmorgan nods
09:18 jeff org.patron_opt_boundary = 1 at the top of tree (establishing automatic opt-in at same-system libs), and set org.restrict_opt_to_depth = 1 at some system levels where patrons should be prevented from being opted in at other systems.
09:18 jeff As mentioned above, I don't think it hit the performance impact until I actually opted in a single user as a test.
09:20 jeff until we can opt in with org lassos, I'm probably going to automatically opt all users in one system into another system.
09:23 * Dyrcona wonders if !{history} works in a bash script...
09:24 Dyrcona Nope: "command not found"
09:24 Dyrcona For the record, I didn't think it would.
09:25 Dyrcona BTW, jeff, I'm having fun with a slow query, too, and I'm writing a script to pg_restore a database, run vacuumdb, and then a bunch of SQL scripts on my training server.
11:32 Dyrcona Has anyone else noticed that actor.usr_delete() sometimes bails on deleted users? (I've not actually observed this, but data that I've collected strongly suggests this.)
11:40 Dyrcona And, a closer look at some of the data and related scripts indicates that no, there isn't a bug with actor.usr_delete().
11:41 Dyrcona We used to have a version of actor.usr_delete that didn't actually scrub the data because it would create too much load/time out.
11:42 Dyrcona It looks like these users were deleted originally when that function was in place.
11:42 Dyrcona Some of them have just, somehow, been updated since then.
12:03 rjackson_isl_hom joined #evergreen
12:09 * Dyrcona keeps a wary eye on the database as A/T slogs through 172,852 overdue notices.
12:12 berick Dyrcona: beware our utility server ran out of memory doing similar.  should probably break them up into chunks.
12:13 AFloyd__ joined #evergreen
12:14 Dyrcona We'll see.
12:14 Dyrcona The utility server is only using 10GB of RAM so far. :)
12:15 Dyrcona And, 1.4G of swap. :)
12:16 jihpringle joined #evergreen
12:31 collum joined #evergreen
12:39 mrisher_ joined #evergreen
12:59 jihpringle joined #evergreen
13:25 Bmagic Dyrcona: we get an occational ticket to manually delete a staff member when the staff client times out. This is usually because the DB function doesn't complete in the alotted time. We run the function by hand in psql and it can take all the time it needs. (5 minutes sometimes) depends on how much "stuff" the staff has accumulated. Sometimes it can number in the 100's of thousands of rows to shuffle around
13:29 Dyrcona Bmagic: I know, but 1 patron in our database is not a problem anymore. There's some "microtransaction" not closed, i.e. a rounding error.
13:30 Dyrcona In this case, I'm pretty sure that these patrons were deleted before we switched back to the mainline function and they slipped through the cracks of my cleanup routine.
13:58 nfBurton joined #evergreen
14:33 mrisher joined #evergreen
14:46 jihpringle joined #evergreen
14:51 jongeorg joined #evergreen
14:53 jongeorg left #evergreen
15:08 collum joined #evergreen
15:34 jihpringle joined #evergreen
16:32 csharp Bmagic: we saw a similar issue re: user deletions (merges in our case) and it turned out we needed to add some indexes - adding some RAISE NOTICE statements in the function might help find the bottleneck
16:42 sticks joined #evergreen
16:43 sticks heyo!
16:43 sticks How we doing today?
16:46 jeff sticks: greetings.
16:47 sticks +jeff: o/
16:56 sticks jeff: do you know any good 3rd party self checkouts for evergreen?
17:00 miker jeff: your observation from this morn' re slow plan from a now-not-empty-but-tiny table, that actually came across the pg-hackers list recently.  the difference in default (assumed) stats between never-touched and 1-page tables is .... weirdly huge, and based on guessing that the page is 100% packed with the smallest possible versions of rows for the table.  and, unhelpfully, autovac would never hit the opt-in table if it never grew.
17:09 jeff sticks: in my experience most self checkout implementations talk SIP, and Evergreen talks SIP, so your options are pretty wide open.
17:10 sticks jeff: thanks
17:10 sticks I might need help setting up that later tomorrow
17:11 sticks Do they support up to SIP3
17:11 sticks ?*
17:13 jeff I haven't seen a single instance of SIP3 in the wild. The standard seems to have gotten stuck after 3M abandoned it and left it on NISO's doorstep.
17:13 jeff SIP2 is what I see, and what Evergreen supports.
17:14 sticks Yeah, thats what i'm seeing on the google
17:14 jeff of course, *every* SIP2 implementation has its quirks and differences, though not as bad as some similar standards
17:16 jeff miker: coincidence! do you recall the thread title?
17:18 sticks jeff: I can't seem to find a good solution on google for what I'm typing in, I typed sip2 self checkout, any ideas on where I should start?
17:18 sandbergja joined #evergreen
17:19 sandbergja Note: bug 1849212 is ready for more testing
17:19 pinesol Launchpad bug 1849212 in Evergreen "Course Materials Module" [Wishlist,New] https://launchpad.net/bugs/1849212
17:20 jeff sticks: I see a lot of the usual suspects when I search for: library self checkout
17:20 jeff including some vendors, some buying guides from industry publications, etc.
17:20 sticks Think I found one
17:20 sticks https://code.google.com/archive/p​/open-source-self-check/downloads
17:22 jeff I thought lib-web-cats might have had a search field for self checkout vendor, but I'm not seeing it.
17:23 mmorgan left #evergreen
17:23 jeff https://americanlibrariesbuyersguide.com/Listi​ng/Index/Automation/Self-Check_Systems/799/394 shows up in that google search, but I'm not sure how current it is, as it doesn't reflect at least one recent major merger/acquisition.
17:23 jeff sticks: oh, are you looking for some open source software for doing self checkout?
17:24 sticks Yeah
17:24 sticks I found one, the google link I poseted
17:24 sticks Supports SIP2 out of the box
17:24 jeff Ah. Not sure what's out there. My first suggestion would be to look at what's built in to Evergreen.
17:25 jeff I don't know if that code/project has a new home, but everything on code.google.com is a point-in-time archive of mostly abandoned projects that didn't migrate off the platform before Google shut it down.
17:27 sticks Yeah, It seems to run alright with no config on PHP
17:28 sticks I'm asumming we set the SIP_IP to the ip of the sever and a user and passsword made in evergreen?
17:33 sandbergja joined #evergreen
17:49 jihpringle joined #evergreen
18:00 jeff_ joined #evergreen
18:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:18 mantis1 left #evergreen
18:30 gmcharlt berick: question re the manage authorities branch - in a large database, genre/form headings (and other broad headings) can easily have tens of thousands of linked bibs
18:31 sandbergja joined #evergreen
18:32 gmcharlt although open-ils.search.authority.main_entry is returning only the ids of those bibs, I have a concern about the potential performance if the interface tries to fetch or deal with one of those
18:32 gmcharlt (of course, if change propagation is turned on, you wouldn't want to actually try saving an edit to the main heading of such an authority record)
18:32 gmcharlt (but that's a separate issue)
18:34 * oleonard waves to gmcharlt
18:35 * gmcharlt waves back
18:37 gmcharlt berick: yeah, the prospect of open-ils.pcrud.search.rmsr "211cac11a4f991dba0f625ef08d9​a075",{"id":[{50,000-element array ... gives me pause :)
18:38 abowling1 joined #evergreen
18:50 abowling joined #evergreen
20:19 sandbergja_ joined #evergreen
20:25 sandbergja_ joined #evergreen
21:33 dbwells joined #evergreen
21:35 dbwells joined #evergreen
22:01 sandbergja joined #evergreen
23:51 dbwells joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat