| Time |
Nick |
Message |
| 07:41 |
|
dguarrac joined #evergreen |
| 08:44 |
|
collum joined #evergreen |
| 08:51 |
|
mantis1 joined #evergreen |
| 08:52 |
mantis1 |
When adjusting a hold rule to implement age hold protection, does this enforce the protection period for any items with a retroactive active time set (before the date it's set) or does it only work for items set as active after the hold rule is adjusted? |
| 09:05 |
Rogan |
time isn't a a human construction but measuring it is. look at what is happening with atomic clocks at different sea levels and thus incredibly small gravitation differences. |
| 09:06 |
Rogan |
mantis1 - it looks at the active time of the item, it doesn't care when the active time was set |
| 09:08 |
mantis1 |
Rogan++ |
| 09:15 |
|
mmorgan joined #evergreen |
| 09:27 |
|
Dyrcona joined #evergreen |
| 09:38 |
mantis1 |
If a shelving location is deleted, would that location show up in the reporter as options still? |
| 09:38 |
mantis1 |
not sure if it does that to track past circulations |
| 09:44 |
mmorgan |
mantis1: Yes, shelving locations that are flagged as deleted will show up in the reporter. |
| 09:45 |
mantis1 |
mmorgan++ |
| 10:01 |
Rogan |
you can filter by the deleted flag of course but copies can still be attached to them |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:27 |
|
sandbergja joined #evergreen |
| 10:43 |
Dyrcona |
jeff: Lp 2111925 |
| 10:43 |
pinesol |
Launchpad bug 2111925 in Evergreen "Race condition with autorenew and checkin" [Undecided,New] https://launchpad.net/bugs/2111925 - Assigned to Jason Stephenson (jstephenson) |
| 10:49 |
Dyrcona |
I have a program to force the race condition. Maybe I'll add that to the bug later. |
| 11:20 |
|
Christineb joined #evergreen |
| 12:04 |
|
jihpringle joined #evergreen |
| 12:13 |
Dyrcona |
Heh. Invalidating the event in the reactor is harder than it should be. :) |
| 12:13 |
csharp_ |
Dyrcona: didn't you mention an issue with high RAM running A/T on Redis? |
| 12:15 |
Dyrcona |
I think so, yes. It looks like a memory in cstore or somewhere like that. |
| 12:16 |
Dyrcona |
Let me check my notes/programs. |
| 12:17 |
Dyrcona |
Of course I can't find it right now. |
| 12:18 |
Dyrcona |
What I recall is there's a memory leak(s) in the Evergreen C code. I could make drones crash with both Redis and Ejabberd. It happens faster with Redis. |
| 12:19 |
csharp_ |
ok - thanks - that's enough for now - if you come across details, I'm interested |
| 12:19 |
csharp_ |
ejabberd is dumb because of the arbitrary "your message is too big so I die now" |
| 12:20 |
csharp_ |
but I've been able to run multiple concurrent a/t processes without RAM trouble |
| 12:20 |
csharp_ |
hoping Redis would help, but we'll see |
| 12:20 |
Dyrcona |
Well, I just found a stacktace from April of last year that might be related. I compiled opensrf and evergreen with -g and attached gdb at one point. |
| 12:21 |
Dyrcona |
I think there's also an issues with drones running too long with Redis. I seem to recall seeing the same PIDs hanging around longer with Redis than with Ejabberd. |
| 12:23 |
Dyrcona |
It could be that Ejabberd somehow sends more messages to drones so that they recycle more quickly. I need to dig into this again, but I get bounced from one thing to another, so I only ever get so far, then I feel like I'm starting over from the beginning when i finally get back to it. |
| 12:23 |
csharp_ |
so many things are like that |
| 12:24 |
csharp_ |
so far nothing has been killed, just high RAM leading to high CPU load |
| 12:24 |
Dyrcona |
It might help if you drop the max_requests settings on the c services, particularly cstore and pcrud. |
| 12:25 |
csharp_ |
the ITS servers are super resilient and fast - almost unbound by RAM/disk constraints - especially when compared to our experience running on bare metal |
| 12:25 |
Dyrcona |
I've had oom-killer kick in, and I've seen Redis report that it could not allocate RAM. Having no swap at all also causes things to crash much faster. |
| 12:26 |
Dyrcona |
I haven't looked at this for a while. You could probably find something in the IRC logs over the past year or so. |
| 12:27 |
csharp_ |
I'll dig - thanks |
| 12:27 |
Dyrcona |
I *might* have opened a Lp bug about memory leaks, but I know that I meant to if I didn't. |
| 12:28 |
csharp_ |
everything's dropping lower after one of the concurrent processes finished |
| 12:29 |
csharp_ |
so I guess the immedate strategy would be to limit concurrency via cron |
| 13:00 |
csharp_ |
Dyrcona: lowering cstore max children, which we tend to over-allocate pre-Redis, seems to have helped |
| 13:00 |
csharp_ |
"we" = "PINES" |
| 13:37 |
pinesol |
News from commits: LP2088295: Angular Circ: Typo when charging for a damaged item <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=23a2c93a6ac02928c1c6f22570f5fc14f628be26> |
| 13:38 |
Dyrcona |
Looking at O::A::Trigger::Event, I think the solution of calling die() to set an error is the better solution. It would be messier (and wrong) to invalidate the event while the reactor is running. Looks like it might cause more issues than it resolves. |
| 13:39 |
Dyrcona |
To do it "right" would require changes to Event.pm. |
| 15:34 |
|
mantis1 left #evergreen |
| 15:47 |
|
sandbergja joined #evergreen |
| 15:51 |
|
Dyrcona joined #evergreen |
| 15:52 |
Dyrcona |
ubuntu-- |
| 16:16 |
Dyrcona |
I thought my laptop camera was supposed to have mainline kernel support in Linux 6.11. I upgraded my work laptop to Ubuntu 25.04 and kernel 6.14.0-15, and the camera still is not found. |
| 16:23 |
|
Dyrcona joined #evergreen |
| 16:32 |
Dyrcona |
dell-- intel-- ipu6-- |
| 16:32 |
Dyrcona |
alderlake-- |
| 17:00 |
|
mmorgan left #evergreen |
