| Time |
Nick |
Message |
| 00:41 |
|
jblyberg joined #evergreen |
| 07:27 |
|
collum joined #evergreen |
| 07:37 |
|
kworstell-isl joined #evergreen |
| 07:38 |
|
redavis joined #evergreen |
| 07:59 |
|
bott-grpl joined #evergreen |
| 08:09 |
|
BDorsey joined #evergreen |
| 08:29 |
|
sandbergja joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:49 |
Stompro |
Hmm, lsb_release isn't installed on my debian bookworm containers... so my postgres repos were not set correctly since that relies on lsb_release -c |
| 08:57 |
Stompro |
the lsb-release package may need to be included as a debian dependency. |
| 08:59 |
|
Dyrcona joined #evergreen |
| 10:16 |
Stompro |
I saw an article about replacing memcached/redis as a caching server by using postgresql unlogged tables. https://martinheinz.dev/blog/105 |
| 10:17 |
Stompro |
Plus an older article about the performance of Postgres vs Redis vs memcached - https://www.cybertec-postgresql.com/en/postgresql-vs-redis-vs-memcached-performance/ |
| 10:19 |
Stompro |
Our memcache cache size never seems to get that large, less than 3G of memory used, so would probably fit on our DB server without any trouble. |
| 10:22 |
|
kmlussier joined #evergreen |
| 10:55 |
|
briank joined #evergreen |
| 11:20 |
Dyrcona |
Stompro: We had 3 memcached servers running at one point, each consistently using over 2GB, so typically 6+GB. Unlogged tables might work. I'll save those articles for later. |
| 11:21 |
Stompro |
That second article wasn't that great, the benchmarking wasn't very well done. |
| 11:22 |
Dyrcona |
Benchmarking can be tricky. |
| 11:29 |
Dyrcona |
gmcharlt | Stompro: Apropos Lp 2038664, something like this might work: grep VERSION_CODENAME /etc/os-release | sed s/VERSION_CODENAME=// |
| 11:29 |
pinesol |
Launchpad bug 2038664 in Evergreen "Debian Bookworm install - lsb-release package dependency" [Medium,Confirmed] https://launchpad.net/bugs/2038664 |
| 11:30 |
Dyrcona |
Or even a single line of sed... It would be nice if there was a standard way to do this.... :P |
| 11:32 |
Stompro |
I know, like a linux standard, that was installed as part of the base system. |
| 11:35 |
Dyrcona |
Exactly! :) |
| 11:36 |
Dyrcona |
S'allright, I also deal with BSD on occasion. That |
| 11:36 |
Dyrcona |
's a whole other story. |
| 11:37 |
Stompro |
My BSD is limited to PfSense and Freenas (trunas core) usage. |
| 11:37 |
Dyrcona |
I'm OK with installing lsb-release. It works for now. |
| 11:39 |
Dyrcona |
I've used OpenBSD and FreeBSD for various purposes for years. My primary desktop was FreeBSD for over a decade. |
| 11:43 |
Dyrcona |
My current home router is a little, low power PC with OpenBSD. |
| 11:53 |
Dyrcona |
Thinking about the unlogged table for cache thing, and having read the Cybetec article, but not the other, I don't know that it would really buy us anything. We'd still be looking at connection limits, etc., with PostgreSQL. I wish I still had some of the data, but I recall looking at the stats on our memcached servers a few times in the past, and they were often hammered. Not sure we'd want to add that load to PostgreSQL |
| 11:54 |
Dyrcona |
It would be an interesting concept to try, though. It might turn out to be great. |
| 12:00 |
Dyrcona |
So, I've started reading the first article, and I wonder how this is going to work with varying times to live for cache keys, like authsessions. I suppose we already have that info in org unit settings, so we could use that somehow. Maybe an additional column on the cache table? |
| 12:08 |
|
jihpringle joined #evergreen |
| 12:11 |
JBoyer |
Dyrcona, I think the hope for storing authtokens in Pg isn't that it's used directly, but polled when memcached doesn't have an authtoken more as a fallback. |
| 12:12 |
JBoyer |
Oops, or I missed Stompro's earlier mention about doing pretty much that. :) |
| 12:14 |
JBoyer |
Anyway, there's room for more than 1 cache system, so long as service is less likely to fall over when one has trouble rather than more likely. |
| 12:14 |
jeff |
oh hey, missed some conversation here related to bug 2038664 before I commented. oops! |
| 12:14 |
pinesol |
Launchpad bug 2038664 in Evergreen "Debian Bookworm install - lsb-release package dependency" [Medium,Confirmed] https://launchpad.net/bugs/2038664 |
| 12:16 |
jeff |
anyway, Stompro++ Dyrcona++ gmcharlt++ |
| 12:16 |
Dyrcona |
JBoyer: Well, I'd also be concerned about max connections on the database as well. We've had many connections to memcached in the past. |
| 12:16 |
Dyrcona |
heh... also/as well. redundant much. :) |
| 12:17 |
Dyrcona |
jeff++ |
| 12:19 |
jeff |
I was amused that we use lsb_release -sc and lsb_release -cs. :-) |
| 12:20 |
Stompro |
jeff++ thanks for the details. The proxmoxVE container template for Bookworm seems to not be installing/containing lsb-release in my specific case. |
| 12:37 |
Dyrcona |
libvirt/qemu VMs do seem to get lsb_release installed. |
| 12:37 |
Dyrcona |
It wouldn't hurt to add it to the prerequisites. |
| 12:37 |
jeff |
There are various things that can pull the package in, including cloud-init and open-vm-tools, etc. |
| 12:37 |
Dyrcona |
In my case it's probably cloud-init. |
| 12:38 |
Dyrcona |
Well, they're both installed. :) |
| 12:38 |
Dyrcona |
Oh, I should check the bookworm vm, shouldn't I? |
| 12:40 |
Dyrcona |
Huh. Neither is installed on the Bookworm VM, but an Ubuntu VM has them both. |
| 12:40 |
Dyrcona |
I guess it doesn't matter. |
| 12:42 |
Dyrcona |
JBoyer: Do you have a query handy (that you could share) that you use to feed marc_export for Aspen? |
| 12:43 |
Dyrcona |
I wonder if I should skip non-member org_unit and opac_visible = FALSE locations, or does it mater with --exclude-hidden. (I'm getting some mild pressure to send them something soon, and it takes all night to get a regular export on my test systems.) |
| 12:50 |
Dyrcona |
`apt-cache rdepends --installed lsb-release` says python3-apt. |
| 12:52 |
|
kmlussier joined #evergreen |
| 12:55 |
Bmagic |
I know I've asked this before: why do we keep rows in the metabib schema for deleted bibs? |
| 12:56 |
Dyrcona |
So staff can find them to undelete them if necessary. |
| 12:57 |
Bmagic |
and a better question might be: is it safe to wipe that stuff out? Like if a bib has been deleted more than x years, might be time |
| 12:58 |
Dyrcona |
Well, it will come back with an ingest, i.e. pingest or some other is run, but there's no real harm in deleting it. |
| 12:58 |
Dyrcona |
You might be surprised how often deleted stuff comes back. |
| 12:59 |
Dyrcona |
...Particularly copies. |
| 12:59 |
Bmagic |
oh really! that's a bummer |
| 13:00 |
Dyrcona |
I seem to recall there's an option to skip deleted records on the db ingest functions or somewhere, but I'm about to grab some lunch, so I leave that as an exercise for the reader. :) |
| 13:01 |
Bmagic |
have a good lunch! |
| 13:17 |
jeffdavis |
I've deleted metabib field entry rows for our deleted bibs before and it didn't cause any obvious harm |
| 13:18 |
jeffdavis |
but yes, they do come back |
| 13:48 |
JBoyer |
Dyrcona, I do. rhamby put some together that I made some changes to. Will throw a tarball someplace. |
| 13:51 |
|
jihpringle joined #evergreen |
| 14:39 |
JBoyer |
not so much "someplace" as "at your sigio email" because lots going on. |
| 15:58 |
|
jihpringle joined #evergreen |
| 16:03 |
Dyrcona |
JBoyer++ Thanks for the scripts! |
| 17:06 |
|
mmorgan left #evergreen |
| 17:39 |
|
jihpringle joined #evergreen |
| 17:57 |
|
sandbergja joined #evergreen |
