yeah, verifying it, the setting was necessary to make it behave in the 2gb memory on the VPS, on my pc it doesn't do this stalling thing that it was doing on the vps
i think that may actually have been the main problem i was having with the other refactored version... because a lot of those changes now are in the realy repo so, meh, shrug, it works, carry on
i get quite agitated when my relay seems to be buggin, really makes me tense
nah, that didn't seem to work either... i guess i'm gonna have to do some memory and cpu profiling, fortunately i have that all ready to go as well
haha just as i was writing that i saw some apple mobile device using person was accessing the API on my relay on the VPS just now
so, looking at top on my VPS i can see that realy is using about 1gb of memory... the stalling was probably mainly because it was blowing out into swap... i might actually try dialing down its memory limit target to 100mb and see how that works
well, i set it to 100mb and that didn't change the amount of memory it uses
didn't seem to do anything, but setting it to 1gb was definitely causing a problem
default is 250mb anyway, seems to be about right, and in reality it uses 1gb... that's fine i guess... it does make the minimum requirement for a vps at 2gb memory tho
it actually now seems to be working, the memory oscillates between about 400mb and 600mb now... i found a good doc on go.dev about it and that's the expected pattern
i lowered the memory limit to 100mb and gc ratio to 20% nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj that seemed to do the trick
yes it is also more responsive now too
i still think i need to examine the thread handling a bit somewhere, it's difficult though because of the hybrid request/socket pattern of the nip-01 architecture
still, 600mb means a lot more space for database disk caching
