This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html Set by lizmat on 8 June 2022. |
|||
04:45
Some-body_ joined
04:46
DarthGandalf left
04:48
Some-body_ is now known as DarthGandalf
08:18
dakkar joined
13:13
jaguart joined
13:20
jaguart left
13:21
jaguart joined
14:08
kjp left
15:12
kjp joined
17:00
dakkar left
|
|||
_grenzo | I keep segfaulting raku | 20:15 | |
$script-path.IO.lines.rotor($batch-size, :partial).race.map: -> @batch { my $q = @batch.join("\n"); try { my @res = $dbh.execute($q).values; } CATCH { default { say "Error: $_"; } } $dbh.finish; $lines-done += @batch.elems; }; | |||
batch-size = 1000, The file $script-path has 4_581_526 lines of sql updates | 20:16 | ||
Welcome to Rakudo™ v2024.05. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2024.05. | 20:17 | ||
antononcube | I detect very recent migration from moar-2024.04 to moar-2024.05. | 20:18 | |
(Maybe with hopes for less segfaulting...) | |||
_grenzo | I have both...they both segfault | 20:19 | |
antononcube | 🤣 2️⃣ | ||
_grenzo | You know of any way to gather info on why they segfault | 20:20 | |
antononcube | Hmm... maybe the professional Comma IDE versions help with that... | 20:23 | |
_grenzo | I'm guesing it has something to do with the file size as it can finish other smaller files | 20:31 | |
gfldex | _grenzo: if a Lock around `$dbh.execute($q).values` makes the segfault go away, then there is somthing in DBIish not quite threadsafe. | 20:53 | |
tonyo | iirc DBIish is not threadsafe | ||
_grenzo | Using DB::Pg | ||
but I'll check | 20:54 | ||
Thanks | |||
ab5tract | I also wonder if there could be an issue with tallying the $lines-done | 20:55 | |
_grenzo | There was originally as I was doing $script-path.lines.elems for a 4m+ file. It would die on that | 20:56 | |
I changed it to my $lines-total = qqx{wc -l $script-path}.words[0]; | |||
ab5tract | Also, I believe that this map block will be executing in batches of 64 across N degrees | 20:58 | |
I think you might want to renove the rotor and adjust the batch size directly in race | 20:59 | ||
At least I think that would make it easier to reason about | |||
Re: $lines-total, did Raku segfault when you did IO.lines.elems? Or did you get an OOM? | 21:01 | ||
_grenzo | segfault | 21:02 | |
or sometimes just killed | |||
ab5tract | Dang :( | ||
_grenzo | lock did not seem to hellp | 21:03 | |
ab5tract | What I meant about rallying $lines-done is that maybe multiple threads are trying to set that variable at the same time and cause a collision | ||
s/rallying/tallying/ | 21:04 | ||
_grenzo | That could be | ||
ab5tract | Moving the $lock.protect to be around that line would test that theory | 21:06 | |
_grenzo | Trying that now | 21:07 | |
that lock is looking goot so far | 21:08 | ||
BTW removing rotor broke something | 21:09 | ||
ab5tract | Or also docs.raku.org/type/atomicint#sub_atomic-assign | ||
Ah then keep it :) | |||
Like I said, I don’t do much with race/hyper so I don’t have many tips on how to hold it correctly | 21:10 | ||
_grenzo: please do report on any successful 4M+ SQL statement run :) (and of course any other issues you might encounter on the way) | 21:24 | ||
_grenzo | 1M worked. | ||
I'll let you know on the others | |||
trying the atomic-fetch-add on another 1M to see if it's faster than lock | 21:26 | ||
ab5tract | Cheers! The atomicint approach should be a bit faster than using a lock, but glad that it seems we fixed your segfault | 21:30 | |
librasteve | ⚛️ | 21:31 | |
_grenzo | Thank you! | 21:38 | |
Attempting 4.6M rows. Expect it to take 25min | 22:05 | ||
Progress: 4579526/4581526 99.95634642% - 1504.612250511 | 22:30 | ||
25 min | |||
4.6M rows successful. Thanks again |