| 25 Nov 2025 | |||
| melezhik_ | it's possible to run web app by `docker exec -it sparman worker_ui start` | 16:22 | |
| [Coke] | Yup, and with the base image, I can't run dmesg to figure out why | ||
| melezhik_ | can you say `sparman worker_ui status` from within container ? | 16:23 | |
| [Coke] | AHA | ||
| docker run --privileged -e "container=docker" --rm -it --name agent -p 4000:4000 -e BRW_AGENT_NAME_PREFIX=cokebot agent | 16:24 | ||
| ^^ that enables dmesg. | |||
| melezhik_ | ok | ||
| [Coke] | [ 7399.502740] Out of memory: Killed process 18529 (raku) total-vm:1929832kB, anon-rss:552116kB, file-rss:420kB, shmem-rss:0kB, UID:0 pgtables:1700kB oom_score_adj:0 | ||
| melezhik_ | yeah, expected | ||
| sparky web which is a cro web app is quite demanding on RAM | |||
| I guess at least it needs about 2-4 GB RAM | 16:25 | ||
| 4 ideally | |||
| ab5tract | :O | ||
| melezhik_ | but it does not leak | ||
| ab5tract | there was one of these running in each agent when we were doing multiple agents | ||
| no wonder the computer kept freezing lol | |||
| melezhik_ | Oh, sorry ))) | ||
| [Coke] | found the memory settings in docker desktop on ma... | 16:26 | |
| mac | |||
| ok, restarted in priv'd mode with 20GB memory 4GB swap | 16:27 | ||
| (will probably start impacting my actual laptop if it gets greedy. :) | 16:28 | ||
| Might want to have two running instances, one for the web app, one for the testing. | |||
| (because some of the tests are themselves memory hungry, and you don't want them to clobber the webapp) | 16:29 | ||
| ok, will leave *this* running for a bit and see if we do better. | 16:30 | ||
| melezhik_ | . | 16:41 | |
| [Coke] | correct me if I'm wrong, but there is no effort to order the jobs with least to most dependencies? | 16:42 | |
| so I could get as my first four jobs things like Cro and Red, which are just going to take a LONG time to test. | |||
| AND you're testing all the dependencies as well? | 16:43 | ||
| if we're not saving the fact that we've tested the dependencies, we can at least install the deps with --/test so we're not spending time running those tests 2x. | 16:44 | ||
| (e.g. my first job this run was Colletion, which has a huge # of deps) | 16:45 | ||
| "Collection" | |||
| Or maybe have some more logic in terms of which groups of modules are handed out - so instead of X unrelated modules, maybe we get some with shared dependencies for a speedup? | 16:49 | ||
| Would also be nice if we had a way to analyze the logs to determine what was being tested *when* the OOM killer happens, so that we can narrow the list of suspected modules to perhaps add to the skiplist | 16:51 | ||
| looks like one job completed (with an install failure on Color::Named) | 16:52 | ||
| melezhik_ | [Coke]: another way to see what jobs are completed by looking at centralized orchestrator ( we call it o10r ) dashboard at brw.sparrowhub.io/builds | 16:53 | |
| you will find $agent_name.$job_number.report jobs here | 16:54 | ||
| for example brw.sparrowhub.io/project/cokebot-9...094.report | |||
| "correct me if I'm wrong, but there is no effort to order the jobs with least to most dependencies?" yes we - can traverse modules "river" by modules sorted by reverse dependencies count | 16:55 | ||
| currently this is commented - github.com/melezhik/brownie/blob/6...wfile#L151 | 16:56 | ||
| but if we think this is more optimal way to test modules it's easy to enable | 16:57 | ||
| "Would also be nice if we had a way to analyze the logs to determine what was being tested *when* the OOM killer happens" sure, if or cause RAM is eaten by module test not by sparky web itself | |||
| "so I could get as my first four jobs things like Cro and Red, which are just going to take a LONG time to test." - yeah, but bear in mind once those LONG list of decencies is installed, the further modules tests are going to be presumably faster given that some or many dependencies are already met | 16:58 | ||
| so "strategically" if we run tests on distributed pool of agents it works for good | 16:59 | ||
| because eventually all agents will build up cache of dependencies which makes it faster to install further modules, but this is just a hypothesis, I might be wrong here | 17:01 | ||
| "so we're not spending time running those tests 2x." we never run tests twice for that matter, as zef would just skip installing dependencies ( and so running tests ) if they are already installed | 17:02 | ||
| tests total: 1000 | finished tests: 625 | 18:22 | ||
| so far | |||
| I made some performance optimization to skip modules already tested by other agents , this should give some increase as well | 18:23 | ||
| to be more accurate to synchronizes such an information across all agents more frequently and faster | 18:36 | ||
| [Coke] | melezhik: if module A depends on moduleB: tests for B and A are run. What then happens when module B comes up in the list? Instant success because it was already installed? Or do you run the tests again at that point? | 20:28 | |
| releasable6: next | 21:01 | ||
| releasable6 | [Coke], Next release in ≈24 days and ≈21 hours. There are no known blockers. 0 out of 29 commits logged | ||
| [Coke], Details: gist.github.com/0e24e397ec24021522...37af2bee02 | |||