Печально, ICH9 действительно без AHCI был, забыл за давностью лет. У msi один мануал на пачку плат, так что мне просто любопытно - у вас этого пункта в биосе вообще нет?
SSD в режиме эмуляции IDE работать должен. При этом наверняка не будет TRIM и надо намеренно искать SSD с внятно реализованным сборщиком мусора. Но разница в латентности доступа от более медленного интерфейса никуда не девается, упереться на случайных операциях в интерфейс весьма сложно. Разница в производительности с механикой HDD всё равно будет огромна.
Можно для эксперимента взять PCI-E x1 платку контроллера с парой SATA портов и жить на ней.
Я не понял, зачем вам вообще понадобился файлик. Почему вы из своего приложения можете дёрнуть cat (т.е. прав достаточно), но не можете сами читать /dev/ttyUSB0?
Да, из коробки gin не умеет int, есть contrib btree_gin (есть и для gist аналог). Но похоже для пары интов уже имеет значение порядок полей. range по интам умеет.
Впрочем, bitmap index scan может и сам обойти несколько индексов. Не помню, как принято решать вопрос разнообразных комбинаций фильтров.
Почему не сильно дешево?
Взять одну железку на 256гб RAM и проблем с чтения с дисков почти нет.
Например, на ovh от $300 в месяц даже с парой SSD: https://www.ovh.com/us/dedicated-servers/
Скорей всего (я не знаю вашего workload!) вам вполне хватит и 128гб, а то и вообще 64гб под горячие данные. Столько памяти не проблема даже на десктоп поставить.
Можно попробовать один multicolumn gin повесить. Ему, в отличии от btree, порядок полей в индексе пофиг. Постоянно читать всё - всё равно быстро не будет. Чтобы работать адекватно в памяти должны быть горячие данные.
100% промах по буферам, конечно холодную таблицу с диска читать медленно. Даже индекс с диска поднимать пришлось. И work_mem не хватило для bitmap, пришлось скатиться до битмапа по страницам и много recheck'ать по целым страничкам.
Поднимите work_mem для этого запроса. Не скажу на сколько, до пропадания Heap Blocks lossy, т.е. довольно ощутимо от текущего уровня.
Поднимать ли shared_buffers - надо понимать workload базы. Если это холодная табличка и запрос надо редко, можно не трогать. Если она должна быть более горячая - то увеличивать shared_buffers, возможно доставлять память.
> один составной индекс еще решил попробовать тоже btree на поля id и city
id & city? А чем он должен был хотя бы в теории помочь?
Евгений Вольф: всего-то 20 минут? Я уже несколько лет этого понять не могу! Особенно не могу понять, зачем неизвестные мне люди хотят меня добавит и что с ними надо делать.
Та запросто и 60мб/с может быть. Смотря на сколько капитально вы упираетесь в CPU и на сколько аналогичный тест под виндами скатывается к random write вместо seq write.
Для виндов это нативная фс, где-то в тех недрах и сделанная десятилетия 2 назад, если не больше. Она там до сих пор единственная, кстати? К этому артефакту спеки-то хоть опубликовали или всё так же реверсинжинирингом разбирать приходится?
В linux запись в NTFS работает через FUSE, т.е. обрабатывается в пространстве пользователя, а не ядра. Это довольно много жрёт CPU.
Смотреть php://input чтобы понять, что эти гении прислали в этот раз. Если там реально нормальный XML - то скормитьэту строку simplexml или другому вашему любимому парсеру XML.
Смотреть на мониторинг. Графики загруженности сети и дисков. Для сети учитывать, что 100% утилизация невозможна, 900мбит/с уже неплохая пропускная способность, дешёвые сетевые карты могут такое и не переваривать. Можно замерить iperf'ом, сколько ваше сетевое оборудование реально может передать между двумя точками. Для дисков смотреть показатель утилизации, плюс график латентности обработки запросов. Бутылочное горлышко может быть как в сети, так и в диске.
