Либа для сортировки на диске

что за данные / критерии сортировки, если не секрет?

Погугли на external sorting

У меня сходу нагуглилась перловка

http://search.cpan.org/~creamyg/Sort-External-0.18/lib/Sort/External.pm

и Цешная прога:

http://epaperpress.com/sortsearch/txt/ext.txt

обычная утилита sort использует временные файлы.

> обычная утилита sort использует временные файлы.

Кстати, давно хотел узнать, а есть ли у sort ограничение на размер сортируемого файла? Ну, типа 4 гиг на 32-битной машине?

какой сорт, gnu или bsd?

> какой сорт, gnu или bsd?

Оба!

И еще солярку сюда хочу, и АИКС, и что вообще на этот счёт стандарты говорят.

> Кстати, давно хотел узнать, а есть ли у sort ограничение на размер сортируемого файла? Ну, типа 4 гиг на 32-битной машине?

ты ж вроде физик - нагенери файлик гигов на десять да проверь :)

// wbr

>> Кстати, давно хотел узнать, а есть ли у sort ограничение на размер сортируемого файла? Ну, типа 4 гиг на 32-битной машине?
> ты ж вроде физик - нагенери файлик гигов на десять да проверь :)

ps: если лениво генерить давай свой e-mail и я тебе вышлю файлик.

// wbr

> если лениво генерить давай свой e-mail и я тебе вышлю файлик.

:-) Заценил!

Кстати, да -- есть у меня терабайтных файлов, спробую ночью...

гнушный вроде хорошо работает.

Только нужно не забыть что временные файлы он создает в TMPDIR (по умолчанию /tmp). А /tmp часто делают в tmpfs -- tmpfs хоть и может быть очень большим (лишь бы свопа хватило), но по дефолту он всего лишь половина ОЗУ. Так что есть смысл задать TMPDIR=/var/tmp

> обычная утилита sort использует временные файлы.

Да, и причём делает всё очень грамотно.

Только она не очень хорошо многоядерность использует... Вернее, не использует её вовсе. Правда, для внешней сортировки это уже не столь важно.

Запустил вчера sort, к сегодняшнему утру оно перелопатило
1.6 - гиговый файл и 25 - гиговый. Сейчас трудится над
120 - гиговым.

Вот что time выдал:

1.6 GB:
real 14m42.727s
user 14m35.043s
sys 0m6.536s

25 GB:
real 265m51.851s
user 262m59.450s
sys 2m17.521s

Трехгигагерцовый восьмиядерник E5472 на Seaburg'е, 32 гига
оперативки, 4.6 терабайта локального диска, собранного софтовым
RAID0 из 6 SATA дисков, 6 раз страпнутого, файлуха -- xfs.

Слишком долго, у меня в разы быстрее на более слабом железе. Задайте буфер ему побольше параметром -S 2G и сжатие временных файлов параметром --compress-programm=gzip

> и сжатие временных файлов параметром --compress-programm=gzip

у него же "user" доминирует -- то есть на ввод-вывод почти не тратится время.

> Слишком долго, у меня в разы быстрее на более слабом железе.

Можно цифру?

А работает, действительно, как-то уж слишком долго! 120гиговый файл лопатит уже 9 часов, набрала в 14 временных файлах в сумме порядка 50 гиг. Файлы равномерно по времени создаёт и бросает, atime не меняется -- судя по всему, это предсортированные патчи, размера они все одинакового -- по 3.5 гига -- то есть к концу (часов через 10) их будет около 35. Если она станет потом 35-way merge делать, файлуха встанет на уши: параллельное рандомное чтение -- самая тяжелая операция. Посмотрим...

Как с этим файлом покончит, возьмется за 388-гиговый.

Потом попробую буфер побольше ей засунуть. Кстати, какой у неё по умолчанию сидит? Странная цифра -- 3.5 гига... А сама программа сейчас отгрызает 9.2 гига оперативки - куда ей столько, если предсортированные патчи по 3.5?

> ...и сжатие временных файлов параметром --compress-programm=gzip

Мой сорт про опцию --compress-programm ничего не знает.

$sort --v
sort (GNU coreutils) 6.4
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>;.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and Paul Eggert.

в 6.10 есть. дистр - убунта.

120g

real 1501m41.637s
user 1487m38.882s
sys 10m51.121s