rPman

https://stackoverflow.com/questions/34983425/iis-8...

нужно добавить в

<configuration>
   <system.webServer>
      <staticContent>
...
         <remove fileExtension=".txt" />
         <mimeMap fileExtension=".txt"  mimeType="text/plain; charset=utf-8" />
...
      </staticContent>
   </system.webServer>
</configuration>

Типичная ситуация - один разъем на материнской плате (видеокарта процессора), другой разъем на дискретной pci видеокарте, при работе второй, первая скорее всего отключена либо по техническим причинам (не могут работать одновременно в принципе) либо по соображению экономии (процессорная отъедает оперативную память) и включается в биосе.

лить в таблицу (ticker, price, quantity, oper) ежесекундно ~1 млн. строк

колись, у какого брокера и за какие деньги ты получаешь эти данные такого объема?

Есть данные типа level2/3 (когда вместе с событиями trade тебе льют depth update, изменения в стакане или сами события в стакане, это данные дорогие, доступ на большом рынке тебе дадут только с машины в датацентре брокера, где надо платить еще и дорогую аренду сервера. В мире криптовалют эти данные пока бесплатны, к примеру один binance (крупнейший поставщик биржевых событий, сравним с ними coinbase точнее gdax остальные в сумме наверное от силы столько же дадут) и тот дает порядка 4 тысяч событий в секунду, максимум что я от них видел.

По теме вопроса, всегда, в первую очередь нужно задавать вопрос не как и где хранить данные а как ты их будешь читать. Судя по теме с высокой вероятностью тебе не нужены отдельные случайные события, а нужны данные блоками, на интервале, поэтому и в базе хранить данные лучше этим блоками (вот тут уже надо считать, проводить бенчи на основе твоих данных и твоих мощностей), скорее всего тебе хватит почасовые массивы, тогда при любом запросе потока на момент времени x-y тебе нужно читать минимум две записи, это сотни миллисекунд, плюс фильтрация, на эту уходят десятки миллисекунд даже на php, если в базе данные удобно сериализованы, дольше передавать и обрабатывать будешь.

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

Так вот, хранить данные можно буквально в файлах, файловая система - отличная key value база данных (дели по файлам и каталогам на основе валютной пары, биржи, и временного интервала, но на время лучше индекс заводить), работать с такой базой неудобно только при обслуживании (backup/restore) но если изначально организовать хранилище в отдельном разделе, то и работать с ним напрямую.

Одно время я хранил данные в gzip json, но недавно открыл для себя igbinary, чудесная вещь, бинарный при этом тоже пакуется, файлы храни на btrfs со включенным сжатием zstd ultra.

для dual/triple/... channel ребуется чтобы планки памяти были одинакового размера (и куча других условий), иначе этот режим просто не включится но все будет работать нормально.

Технология добавляет системе в производительности (в задачах вычислений), в идеальных условиях тестировщиков памяти +80% к скорости (что нереально в рабочих условиях), простой тест архиватора показывает примерно 7%-10% повышения производительности (это единственное известное мне потребительская задача, где так активно используется память), в 99% других случаев пользователь просто не заметит разницы, считанные проценты.

Поэтому хорошо подумай, дополнительные +8Гб (16 или 24) стоят ли этих 1-10% в скорости работы приложений? Хорошо подумай.