| Time |
Nick |
Message |
| 00:43 |
|
kworstell-isl joined #evergreen |
| 07:03 |
|
kworstell-isl joined #evergreen |
| 07:27 |
|
kworstell_isl joined #evergreen |
| 08:06 |
|
collum joined #evergreen |
| 08:27 |
|
dguarrac joined #evergreen |
| 08:44 |
|
sandbergja joined #evergreen |
| 09:01 |
|
Dyrcona joined #evergreen |
| 09:02 |
Dyrcona |
Wow! An open-ils.trigger drone using 3.3g of RSS. |
| 09:04 |
Dyrcona |
Looks like it is a run pending trigger runner, likely working on leftover AutorenewNotify events from Tuesday. |
| 09:07 |
Dyrcona |
And, it's gone. Must've hit the request limit. |
| 09:07 |
* Dyrcona |
checks logs for what berick said about how many requests it is set to allow on the utility server. |
| 09:08 |
Dyrcona |
OK. That was pcrud and storage. |
| 09:10 |
Dyrcona |
So, my max_requests settings for pcrud, storage, and trigger are 1000. |
| 09:21 |
|
mantis1 joined #evergreen |
| 09:55 |
|
sandbergja joined #evergreen |
| 10:03 |
|
mmorgan joined #evergreen |
| 10:19 |
|
smayo joined #evergreen |
| 10:53 |
berick |
Dyrcona: i have trigger set to 50 max requests on the util server |
| 10:53 |
berick |
some of those big jobs can really hoard ram |
| 10:55 |
Dyrcona |
OK. I was thinking about dropping it to 100 on the dev system. |
| 10:57 |
Dyrcona |
If I change that in opensrf.xml, I only have to restart settings and the affected service, right? |
| 10:57 |
* Dyrcona |
should just know. |
| 10:58 |
Dyrcona |
We should probably have a document on settings tweaks for production systems.... |
| 11:00 |
Dyrcona |
I'll wait until after the current run-pending trigger_runner to restart the service. |
| 11:52 |
|
jihpringle joined #evergreen |
| 12:26 |
|
jihpringle joined #evergreen |
| 13:04 |
Dyrcona |
heh. "Swapon, Wayne." Swapon, Garth." |
| 13:04 |
Bmagic |
Dyrcona++ |
| 14:48 |
|
smayo joined #evergreen |
| 14:51 |
csharp_ |
the bots are celebrating a new year by picking on me |
| 14:53 |
Bmagic |
bots-- |
| 14:53 |
Dyrcona |
bots-- |
| 14:53 |
Dyrcona |
Bmagic++ |
| 14:53 |
Dyrcona |
ansible++ |
| 14:53 |
Dyrcona |
learning++ |
| 14:57 |
csharp_ |
ansible++ |
| 15:04 |
* Dyrcona |
added plays to our Ansible playbooks to make sure that the memory and swap settings happen when we ever build new dev or utility vms. |
| 15:05 |
Dyrcona |
plays? tasks? Same thing, right? |
| 15:06 |
Bmagic |
Are you referring to the result line after the book played? |
| 15:08 |
Bmagic |
Ansible can reachout and execute a playbook across hundreds of servers, so, I believe "plays" is more in line with number of servers that received the playbook. Whereas tasks is the individual pieces of the playbook that are executed. And if the playbook uses IF statements, it's possible the number of tasks differ from server to server |
| 15:08 |
Dyrcona |
No, there was an error message at one point that said 'x is not a valid play' or something like that. Then, there's the tasks key in the playbook. |
| 15:09 |
Dyrcona |
OK. That makes sense, too: a play is a run of a playbook, and a task is something you don in a playbook... |
| 15:09 |
Bmagic |
If each task is named, then it should give you your "user friendly" name back to you when it's executing. |
| 15:11 |
Dyrcona |
Yeah. It does. What I got was "ERROR! 'lineinfile' is not a valid attribute for a Play" Which clued me in that something was missing, i.e. the "tasks" attribute. |
| 15:12 |
Dyrcona |
Copy and paste is not always your friend. |
| 15:12 |
Bmagic |
ah yes, the header needs some setup logic |
| 15:22 |
|
mantis1 left #evergreen |
| 15:58 |
|
jvwoolf joined #evergreen |
| 15:59 |
|
jihpringle joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 18:33 |
|
jihpringle joined #evergreen |
| 22:58 |
|
azureBytes joined #evergreen |
| 23:34 |
|
tiime joined #evergreen |
| 23:35 |
tiime |
Hi |
