| 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/Listing/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 "211cac11a4f991dba0f625ef08d9a075",{"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 |
