That much swap is pointless. If you're thrashing even 100M of swap the box will be unusable anyhow, so reduce your swap image back to 256M or something sane.
Ok, will do, I had originally decided on 2GB as both Ubuntu
documentation suggest 2x your RAM. I did find this
though in the Ubuntu docs which is more like what you recommend.
The general 2x recommendation isn't necessarily unreasonable on a dedicated machine, since while disk is significantly slower than memory, the swapping is still only on behalf of the single environment running on the machine. It does depend on whether you're truly going to be overcomitted (and then thrashing, in which case even a little can be disastrous), or just have a larger allocation than working set. It's still probably reasonable to also have some absolute maximums independent of machine size (e.g., 2GB is probably extreme for a 1GB machine in any case), unless you know a lot about how your working set operates and you're ok with a hit when switching among activities.
Importantly, in a VPS scenario, disk I/O is, in general, more contentious and performance impacting. Unlike memory (which with Xen based systems is guaranteed availability for a given VPS), disk is shared among all other machines on that host. So the already performance compromising disk I/O performance is slowed even further by the VPS contention for host resources.
The bottom line is that in a VPS environment, you want to do whatever you can to keep everything in memory, and there's little benefit to permitting significant swapping as your performance will likely tank horribly.
With respect to the original log, the binary method log would seem to indicate that the source address is connecting to you and just spewing binary data at the server. If you see some consistent addresses in the logs doing that, couldn't hurt to filter them out, though as long as you get your Apache configuration under control so having lots of hits won't overload the machine, having some sporadic screwy connections shouldn't hurt that much.