Need help! Не решается задача, упираюсь в ограничения железа - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Простите чайника, а в х64 есть ограничения? вот первая попавшаяся статья (ну не первая, ладно) Ограничение оперативной памяти для SQL SERVER 2008 под системой x64 - сколько есть оперативы, столько база и съедает.
Может, надо попробовать.
ps может, пригодиться Убираем ограничение в 4 Гб памяти на 32 битных Windows 8 / 8.1
Есть большой объем информации (около 20 Гб в текстовом файле).
Так а почему в текстовом-то? Не проще ли для начала перегнать данные в бинарный вид? Там глядишь, и размер подходящим станет:
Огорчает и объем информации... Было бы там Гиг 10, перенес бы на RAM-диск (по сути, в память), и читал бы сколько влезет
Так а почему в текстовом-то? Не проще ли для начала перегнать данные в бинарный вид? Там глядишь, и размер подходящим станет:
Перейти на 64 битную версию - будет доступно до 16Тб оперативы.
Хранить файл в бинарном виде, чтоб быстрее считывалось.
Обрабатывать файл кусками, по размеру оперативы.
Попытаться сделать предобработку данных для устранения дублирующейся информации.
Есть большой объем информации (около 20 Гб в текстовом файле).
...
И если бы нужно было бы пройтись по этим последовательностям единожды, то я так бы и поступил. Но нужно проходить по ним многократно, каждый раз сдвигаясь немного вперед.
...
А если обрабатывать кусками?
Считать два куска, пусть по 1Гб. Первый кусок обрабатывается и в следующий проход добавить из второго куска "...сдвигаясь немного вперед". Одновременно обрезать начало первого куска (ведь он уже не нужен, т.к. всё время "...сдвигаясь немного вперед". Когда второй кусок закончится считать третий кусок - и теперь добавлять из третьего куска "...сдвигаясь немного вперед". Таким образом в оперативной памяти будут всегда два куска (максимум 2 Гб) и обращений к жёсткому диску будет на порядок меньше.
Перейти на 64 битную версию - будет доступно до 16Тб оперативы.
Хранить файл в бинарном виде, чтоб быстрее считывалось.
Обрабатывать файл кусками, по размеру оперативы.
Попытаться сделать предобработку данных для устранения дублирующейся информации.
Это для какой оси/версии? даже ХРпро х64 физическую до 128 поддерживает, а виртуальную до 16ТБ.
Это для какой оси/версии? даже ХРпро х64 физическую до 128 поддерживает, а виртуальную до 16ТБ.
Есть большой объем информации (около 20 Гб в текстовом файле).
Информация состоит из однотипных последовательностей, их около миллиона.
Необходимо многократно перебирать все последовательности и производить некие расчеты.
Первое, что приходит в голову - прочесть все содержимое файла, заполнить им массив структур, и работать с ними в памяти.
Но не тут-то было, при очередном ресайзе МТ ругается "Memory handler: cannot allocate 5610000 bytes of memory".
Диспетчер при этом говорит, что terminal.exe использует 3.5 Гб оперативки (из 16 физической). Я так понимаю, это из-за того, что процесс может получить только 4Гб.
Советник говорит "Not enough memory (4007 Mb used, 88 Mb available, 4095 Mb total)!!!".
А это - только 15.3% от необходимого объема (а хотелось бы и его в перспективе увеличить).
А больше у меня фантазии не хватает.
Попробовать перекомпоновать эти последовательности так, чтоб получилось много-много кусков, но в каждом - только необходимая на текущий момент информация?
Еще сжать данные (я и так на float-ы с char-ами везде где можно перешел)? Но это даст еще процентов 10-20% максимум, а мне нужно на порядок уменьшить объем..
Подскажите, кто что думает, друзья. За мной не заржавеет )
А в сторону использования БД не смотрели ? Ставим БД, загружаем туда из текстового файла данные. Можно выполнить какое-либо агрегирование данных предварительно для последующих расчетов.
А дальше SQL запросы из эксперта...
СУБД можно и на отдельный сервер повесить, чтобы повысить производительность торговой станции.
Всем огромное спасибо за участие!
Сейчас убегаю в офф-лайн на выходные, но в ПН обязательно всем отвечу и попробую воспользоваться советами.
А в сторону использования БД не смотрели ? Ставим БД, загружаем туда из текстового файла данные. Можно выполнить какое-либо агрегирование данных предварительно для последующих расчетов.
А дальше SQL запросы из эксперта...
СУБД можно и на отдельный сервер повесить, чтобы повысить производительность торговой станции.
Думал об этом. Интересовался мнением:
Еще одна мысль - перенести все в БД (MySQL?) и работать с ней. По идее, БД заточены под такие объемы и постоянное перелопачивание.
Есть эксперты? Кто что скажет?
Какое будет ускорение по сравнению с чтением файла и какое замедление по сравнение с работой в памяти?