Хранение данных с помощью AWE Memory через коллекции / списки / другие контейнеры

Question

Есть ли у кого-нибудь предложения (продукт, наборы инструментов, методы или другое) для хранения и обработки пользовательских данных (коллекций delphi, двоичных деревьев, DIContainers и т. Д.), Которые НЕ ограничивают себя стандартным адресным пространством памяти win32? Иными словами, есть ли в наличии что-нибудь, что могло бы эквивалентно удержанию TList на 10 ГБ, тем самым преодолевая барьер переключателя / 3 ГБ и ограничение 4 ГБ «окна на окнах»?

В идеале нам нужно что-то, что довольно прозрачно для программиста приложений Delphi, но позволяет очень быстрый доступ к данным, хранящимся в его структурах, предпочтительно с помощью поиска ключей. Эквивалент контейнера коллекции delphi вполне подойдет, но его использование памяти должно осуществляться через AWE. Также необходимо позаботиться о отображении и отключении физического пространства, которое он использует, в процесс win32, используя его, то есть это будет прозрачный бит ...

Перемещение данных в базу данных не является ответом - информация должна оставаться в памяти для очень быстрого доступа. Базы данных / таблицы в памяти, которые мы пробовали, не используют AWE, а также имеют медленный доступ. Наши текущие структуры данных Delphi хороши, но ограничивают адресное пространство win32.

Answer 1

Я собираюсь быть полным придурком и сказать вам, что я сделал что-то еще более продвинутое, чем то, что вы описываете ... на работе. Так что, боюсь, это все из закрытых источников. Никогда не видел ничего подобного. Мы объединяем VM, AWE, MMF и (скоро) 32 <> 64-битный IPC в одну большую, среднюю машину обработки данных, занимающую до 64 ГБ памяти и обрабатывающую сотни наборов данных, десятки ГБ каждый .

Но я могу дать вам несколько советов: обмен представления AWE довольно медленный, потому что он принудительно приостанавливает все запущенные потоки во время обмена. Поэтому выбирайте размеры окон разумно (чем меньше, тем быстрее происходит свопинг, но затраты на вызовы ниже при больших размерах курса). Мы установили размеры представления AWE, равные размеру страницы Windows по умолчанию (4 КБ), но только потому, что произвольный доступ работает лучше всего таким образом. Доступ к данным Lineair может работать быстрее при больших размерах просмотра.

Каждое представление может отображаться в любую часть выделенной памяти AWE, поэтому одна вещь, которая может помочь, - это сопоставление только тех страниц в представление, к которому необходимо получить доступ, и попытка сэкономить на ненужных заменах представления (очередь приоритета). приходит на ум).

Кроме того, где-то в вашем проекте должен быть механизм регистрации, который обрабатывает связь между представлением и памятью AWE за этим. И это лучше быть потокобезопасным!

Что касается общего использования: нет, это не вписывается в обычные классы Delphi. Вы должны полностью переключиться на другую концепцию и основывать свои структуры данных на этом.

В любом случае, приятель удачи! Тебе это понадобится ...; -)

Answer 2

Ваша ситуация похожа на нашу, наше приложение использует огромный файл данных, который мы храним в файле с отображением в памяти. Размер файлов составляет около 750 МБ, и мы выделяем из них структуры данных, которые используют до 1,5 ГБ ОЗУ.

Мы не нашли решения для ограничения в 4 ГБ, кроме как перенести часть его в FPC / Lazarus до 64-разрядной версии Delphi, к сожалению. AWE не работает с версиями Vista Home, также мы не смогли заставить его работать с MMF.

Вы можете попробовать отображаемые в памяти файлы с помощью скользящего окна, что означает, что вы динамически создаете представления различных фрагментов файла в зависимости от того, какую часть его использует приложение. Похоже, это не сработает, потому что вам нужен весь файл в памяти сразу.

Answer 3

Похоже, вы, ребята, могли бы подумать о том, чтобы отказаться от текущей базы данных SQL и перейти на 100% -ное решение NexusDB + AWE.

(Вернее, ежедневный доступ к бэкенду SQL и наличие функции экспорта / синхронизации, которая может записывать любые необходимые данные отчетов NexusDB в базу данных отчетов MSSQL.)

W

Answer 4

При условии, что данные загружаются один раз навалом и помещаются в доступную память, NexusDB AWE будет очень очень быстрым. База данных может быть создана как БД только в оперативной памяти, и ей больше не понадобится доступ к жесткому диску при манипулировании.

Answer 5

Проблема с AWE очень похожа на старые, основанные на DOS EMS и XMS - если вы когда-либо использовали их. По существу, диапазон адресуемой памяти зарезервирован, и память за пределами адресуемого диапазона затем сопоставляется с адресуемым диапазоном, когда это необходимо, и не сопоставляется, когда больше не требуется, что позволяет отображать другую память по тем же адресам. Таким образом, большинство не-AWE-осведомленных структур данных или контейнеров не будут работать в таком сценарии - вероятно, потомок TMemoryStream легче построить. Должно быть достаточно просто создать TList или тому подобное, который хранит данные в памяти AWE, он должен отслеживать, где данные действительно хранятся, и вызывать их при необходимости, а также корректировать адреса, когда данные отображаются в адресуемую память. Мне неизвестно о какой-либо библиотеке контейнеров Delphi, использующей AWE, и есть еще одна проблема: 32-разрядные операционные системы для настольных компьютеров не могут использовать более 4 ГБ физической ОЗУ, потребуется версия сервера и поддерживаемая Физическая память зависит от используемой версии, полный список см. здесь .

Answer 6

Вы заявляете, что не хотите перемещаться в базу данных, но как насчет базы данных , которая специально использует AWE ?

Я лично не пробовал, но хотел бы использовать продукты этой компании для своих собственных проектов.

[Редактировать]: NexusDB дружествен к Delphi: он возник из старой разработки Turbopower FlashFiler (но с тех пор продвинулся далеко).

Answer 7

Есть системные вызовы , которые могут это сделать, но это не поддерживается во всех версиях Windows (в частности, Windows XP не поддерживает AWE).

Прозрачность может быть проблемой, поскольку API не может возвращать указатели на объекты. Отображение более 4 ГБ ОЗУ в адресное пространство 4 ГБ означает, что 32-разрядный указатель может быть неоднозначным - вы можете потенциально отобразить разные объекты в одном месте.

Эта двусмысленность означает, что вам придется генерировать прокси для объектов, которые содержат дескриптор, который можно использовать для доступа к «записи». Некоторые версии SQL-сервера используют эту технику для хранения дисковых буферов в памяти AWE. Такой подход, вероятно, будет работать для чего-то вроде строк в матрице, где операции выполняются для всей строки. Более мелкозернистый доступ был бы более рискованным.

Чтобы обеспечить прямой доступ к сопоставленному объекту, вам необходимо реализовать протокол, в котором был сделан доступ к временному указателю на сопоставленную память. Это также потребовало бы, чтобы объект был заблокирован в памяти во время использования - опять же, удар идет вразрез с вашей прозрачностью.

Предполагая, что теперь вы можете получить 64-разрядную версию Delphi, вам лучше перейти на 64-разрядную версию Windows для клиентов, которым требуется больше оперативной памяти.