| Time |
Nick |
Message |
| 05:12 |
|
bshum joined #evergreen |
| 05:39 |
|
rjackson_isl_hom joined #evergreen |
| 05:46 |
|
Christineb joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:32 |
|
rfrasur joined #evergreen |
| 07:50 |
|
collum joined #evergreen |
| 08:26 |
|
mantis1 joined #evergreen |
| 08:33 |
|
alynn26 joined #evergreen |
| 08:35 |
|
nfBurton joined #evergreen |
| 08:55 |
|
jvwoolf joined #evergreen |
| 09:10 |
|
Dyrcona joined #evergreen |
| 10:02 |
|
Keith-isl joined #evergreen |
| 10:34 |
|
mmorgan joined #evergreen |
| 10:50 |
miker |
Dyrcona: a recursive cte could find (or expose) loops, fwiw |
| 10:56 |
Dyrcona |
miker: OK. I'm dealing with the aftermath of an out of memory condition on the main database server last night. A server with 768GB of RAM ran out of memory.... |
| 10:57 |
miker |
ew, gross :( |
| 10:59 |
miker |
well, if/when you get back to looking at the pgtde, you might be able to use something like this to spot a loop: with recursive tree as (select id,parent,array[id] as all_parents, 0::int as depth from permission.grp_tree_display_entry where parent is null union all select c.id,c.parent,p.all_parents||c.id, p.depth+1 from permission.grp_tree_display_entry c join tree p on (c.parent = p.id) where depth < 1000) select * from tree; |
| 11:01 |
Dyrcona |
miker++ I'll give that a try later. |
| 11:05 |
csharp_ |
huh - we have some loops looks like |
| 11:09 |
csharp_ |
no - I was misreading the output - looks ok here |
| 11:12 |
miker |
csharp_: a loop would like like a 1000 element array in all_parents, with a repeating pattern |
| 11:12 |
Dyrcona |
Whee! beam.smp using 260% of CPU.... S'OK, we've got 12 "CPUs" |
| 11:12 |
miker |
Dyrcona: huzzah for threads! |
| 11:18 |
Dyrcona |
HTT is not as good as a real CPU. When I benchmarked Pg on a HTT server, HTT enabled only added up to a 40% performance boost. |
| 11:20 |
Dyrcona |
Also, our thresholds for warning about load are too low. It shouldn't even be a warning until something like CPU count * 2. I've found that a Linux server is pretty responsive until about CPU count * 4 load. |
| 11:26 |
Dyrcona |
Anyway, this a utility server. Our db server has way more threads than that. |
| 12:18 |
|
jihpringle joined #evergreen |
| 12:52 |
JBoyer |
The trouble with load is that it *super* matters what causes the load. If your load is slightly higher than ncpu * 1.5 because of iowait, you're going to have a bad time. It can also be ncpu * 10 and totally responsive if it's totally different. |
| 12:52 |
JBoyer |
I've seen load compared to a weather stone: https://www.geograph.org.uk/photo/6019372 |
| 12:52 |
JBoyer |
The only trouble is that accurately monitoring everything that you need to avoid weather-stone-ness usually means you have someone or someones that just focus on monitoring and what to monitor. |
| 12:54 |
|
collum joined #evergreen |
| 13:38 |
miker |
(oh, I was referring to the fact that beam uses threads, not HTT ... but yes, a hyperthread is def not as nice as a full core!) |
| 14:16 |
Dyrcona |
miker++ |
| 14:17 |
Dyrcona |
miker: Haven't you heard that processes are the new threads? :) |
| 14:29 |
Dyrcona |
miker++ # Again.... |
| 14:43 |
|
tlittle joined #evergreen |
| 14:47 |
miker |
csharp_: still looking good after jeff's patch? (silver lining, this makes me glad that I'm going to be looking at parameter chunking again soon-ish ... I think that would have at least let actor not fall over because then LARGE param handling is done in the drone rather than the listener, and if we've passed a 0.6MB param once, we'll do it again.) |
| 15:58 |
csharp_ |
miker: yes - all is good! |
| 16:12 |
|
jvwoolf left #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 18:02 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 20:43 |
|
Guest61 joined #evergreen |
