Note that the Linux out-of-memory killer is triggered when the combined RAM plus all the swap space (devices and files) are nearly exhausted so assuming Raspbian allocates 2GB of swap, then that means Core must have been using around 3GB, as the OS itself uses 512MB of memory for itself.
If only the RAM is exhausted then naturally, memory pages of processes will start being moved to swap, and as Linux's swap scheduler isn't as efficient as the one in Windows, it's far more likely that your Linux system will just hang when all the RAM is filled because all the CPU cycles are being spent moving pages between bitcoin core from RAM and swap and back again each time Core uses a memory page located in swap.
A dbcache of 500 should leave enough RAM for other processes to breathe with.
You seem to be misunderstanding what "block 269" is...
2021-02-02T01:59:35Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=133, size=46578747, heights=356495...356719, time=2015-05-15...2015-05-16)
It isn't stopping on block# 269... it is stopping on the block file that Bitcoin Core is storing on disk... as you can see, that file actually has 133 blocks stored in it... from Block# 356495 through to Block# 356719
As the others have said, the limited RAM on the Pi is likely your issue... especially with the dbcache setting you have used. dbcache should never really be more than half of your total system RAM (as a maximum!)... and you should only really increase it about the default value when you have a fairly substantial amount of system RAM.
Remove the dbcache setting... and you'll find your Pi should happily (but somewhat slowly) sync without being killed
Thank you very much for the explanation.
I have been testing the network before writing in case there were any problems.
The result is positive and since lowered the RAM to 500. It has been working without interruptions.