Доступная оперативная память на хостинг-провайдере

Question

Я создаю бизнес-приложение, которое будет содержать от 50 000 до 150 000 компаний. Каждая компания (строка БД) представлена ​​4-5 свойствами / столбцами (заголовок, местоположение, ...). ORM - это LINQ2SQL.

Я должен сделать некоторые расчеты, и для этого у меня много запросов для конкретной компании. Теперь я хожу в db каждый раз, когда мне что-то нужно, и он генерирует 50-200 запросов, в зависимости от сложности вычислений. Я попытался поместить все компании в кеш, и для 10 000 строк (компаний) в дБ требуется около 5,5 МБ кеша. В этом случае у меня есть только один запрос.

Это приложение будет на сервере виртуального хостинга, поэтому мои ресурсы ограничены. Мне интересно, что произойдет, если я попытаюсь загрузить, скажем, 100 000 компаний (строк, объектов)? Или положить это в кеш?
Существует ли ограничение по объему оперативной памяти, которое средняя хостинговая компания дает приложению ASP.NET? Зависит ли это от выделенного пула приложений (я могу поместить приложение в выделенный пул)?

Варианты :
- загрузить всю таблицу в объекты C #. Я выполнил некоторое профилирование памяти, для 10 000 объектов требуется 5 МБ ОЗУ
- запросить db для получения ссылочных объектов при необходимости.

Задача: : для данной компании A построить дерево связанных компаний.

Таблица и столбцы :
Компания : IdCompany, Название, Адрес, Контакт
CompanyConnection: IdParentCompany, IdChildCompany

Answer 1

Вероятно, вашим общим хостом будет IIS 7 на Windows Server, работающий как виртуальная машина. Эта машина будет вести себя так же, как любая обычная машина - она ​​«не осознает», является ли она общей или виртуализированной.

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

Сама Windows может начать раздражать вас из-за нехватки памяти, но это не та же «срочность», и приложения будут по-прежнему иметь возможность запрашивать ОЗУ, и она будет продолжать выдаваться (хотя и обслуживаться из файла подкачки). 1005 *

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

Создайте ожидаемое количество объектов в цикле с притворными данными и наблюдайте за потреблением памяти на коробке - рабочий набор рабочего процесса - тот, который нужно наблюдать. Вы можете сделать это в диспетчере задач.

Следите за ошибками страницы. Это события, когда операция с памятью должна была быть направлена ​​на диск.

Кроме того, очень большие наборы объектов могут вызывать длительные циклы сборки мусора> 1 секунды. Это может быть большой проблемой в чувствительных ко времени приложениях, таких как торговля и рыночные данные.

Надеюсь, это поможет.

Обновление: я выполняю аналогичную процедуру кэширования для мега-приложения для интеллектуального анализа данных.

Каждый тип ORM имеет метод GetObject, который использует гигантский кеш или переходит на диск, а затем обновляет кеш: Person.GetPerson (проверить кеш людей, перейти к базе данных, добавить кеш людей)

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

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

Результаты запроса также кэшируются. Конечно.

Если объекты не являются неизменяемыми, каждая запись-объект обновляет свой собственный экземпляр в гигантском кеше, но также приводит к тому, что все кэши запросов, относящиеся к объектам этого типа, аннулируются!

Конечно, в этом приложении записи встречаются редко, так как это в основном справочные данные.