There is no way for me to know if this will help at all, but I had some fun playing. All of this was on a 16 core 16GB desktop running Cygwin. Linux often performs better on some things because Cygwin is really sitting on top of the Windows runtime library.

As an extrapolation from my testing below:
Try -

Code:

sort --parallel 4  --batchsize=256

Since you have four cores - this will improve throughput. It means run four independent threads of sorting - one on each core, break the large file into 256 chunks, sort and then merge 256 chunks (NMERGE in the documentation).

Your data presents problems.

1. The key is the entire line. Using a tag sort (some kind of key compression on the first 64 bytes to turn the data into an integer or a set of 3 integers) speeds up comparison times by an order or magnitude. To make a numeric comparison on the first radix key (if you like the term) use

Code:

-k1n -k2n -k3n

. This will have sort use three 64 bit words, using 3bit translation ( 3 values * 64) for comparison which is three compare ops. versus having to compare 64 characters.

2. Locality. Line 1301010 may really need to be after to line 14 in the final output.
By getting NMERGE to reasonable value ( 300GB/256 = 1.17GB) This creates a first
pass scenario where locality is less of an issue since all of 1.17 will easily fit in memory.

3. sort uses disk intensively. make sure TMPDIR is assigned to a filesystem that is a separate disk with lots of CONTIGUOUS free space. i.e., Pretty much wiped empty.
An SSD will make a huge difference in performance.

I dummied up a file with a 27183337 lines == almost exactly 2GB. I ran it on Cygwin.
Box has 16 cores 16 GB memory.

Code:

$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 8
stack size              (kbytes, -s) 2025
cpu time               (seconds, -t) unlimited
max user processes              (-u) 256
virtual memory          (kbytes, -v) unlimited

Run using 7200 rpm drive not on SSD

Code:

TMPDIR=/cygdrive/e/tmp # not the SSD drive
time sort --parallel 16 --batchsize=32 -o ./sorted bigfile
real    3m2.016s
user    4m24.744s
sys     3m1.015s

Notice the user + sys time adds up to more than elapsed time. Why? parallel.

Code:

TMPDIR=/cygdrive/f/tmp #  this is SSD drive
time sort --parallel 16 --batchsize=32 -o ./sorted bigfile
real     1m18.223s
user    4m19.007s
sys     2m19.016s

This is about 40% of the wall time compared with a slow disk. sys is better due to shorter I/O request queues . And appears to me to be the limiting factor. The number of comparisons was the same as was a lot of the other overhead so user is about the same.