Вы это всерьез ?
Скорее всего и вовсе без индексов всё будет работать с базой на 2000 строк...
ЗЫ. Менял, кстати, в одном из дебилошопов типа престашопа, некоторые части так, чтобы вместо выборки из базы автогенерировался php-файл с функцией с одним switch (для вариантов в 10-100 строк). И учитывая сколько раз эти части вызывались даже был ощутимый профит. Да, можно и кешировать, но не всегда это удобнее и быстрее, а если есть некая функция импорта, то она легко может прям php-код "готовить".
Причем тут кеш проца :) ? Вы правда думаете, что из него пишется что-то в swap :) ?
За соболезнования спасибо, но у меня ныне особо проблем нету.
ОЙ... вы можете оптимизировать ЧУЖОЕ ПО :) ?
Можно к вам обратиться :) ?
Мнеб этот fusion 360 оптимизировать, возьметесь :) ? Ну или какой-нибудь visual studio, тоже было бы неплохо.
А может вы просто оптимизируете для нас всех gcc ? Ну чтобы был оптимизированный :), ведь вам, наверное не трудно :) ?
Тупизна ужасна. Предельное вырождение нации.
Вы правда не понимаете, что смысла складывать на HDD свап-файл нету никакого ?
Это делали только "альтернативно одаренные" и то, только с первыми SSD у которых были большие проблемы с ресурсом.
Может вас на какие-то мысли наведет тот факт, что к некоторым SSD прилагаются утилиты, которые позволяют специальным образом его ЦЕЛИКОМ и ТОЛЬКО под swap использовать :) ? Например от интела видел такую утилиту в комплекте, и даже какие-то патчи для ОС...
Я использую компьютер для профессиональных нужд.
У меня уже давно 32gb ram... поставил бы и 64, но были какие-то проблемы с наличием подобранных модулей.
Купите себе планшет и не влезайте в разговоры людей, которые не "котиков" ищут, а пользуются серьезным прикладным ПО.
Вот ей богу...
Не - это те у кого "свой", на деле "арендованный" офис :)
Ну желательно в москве-сити прям... :)
И главное - секретутка :)
Так и не трогайте базу, зачем вы какие-то 100.000 запросов делаете ?
Не работает даже так. Либо части ОС, либо части прикладного ПО содержат достаточно мест, после которых память не освобождается. Если перегружаться раз в несколько часов - всё работает, если раз в несколько суток или недель, то всю память сжирает. При включенном свопе сжирает его, причем почти без последствий, если он находится на SSD.
Есть и еще одна проблема: некоторое ПО попросту не работает при отключенном swap-файле даже с бесконечным объемом памяти. Как и зачем это сделано непонятно, но факт. Да, зачастую оно "устаревшее", но не всегда можно пересесть на более современное по объективным причинам. (дорого очень как в плане стоимости лицензий, так и в плане "цены перехода").
С вариантом "без SSD памяти дофига, своп отключен" я работал довольно долго, требуются перезагрузки раз несколько суток так уж точно. С вариантом "SSD, swap на SSD памяти дофига" не выключаю семерку месяцами... и стало шустрее - факт.
И через недельку без ребута памяти 0 байт.---------- Добавлено 08.08.2018 в 12:28 ----------
Да-да, конечно, взять и переместить наиболее критичное с точки зрения скорости доступа с SSD на HDD :)
Экономить ресурс на запись... ага :)
Восподи... откуда вы такие беретесь-то...
Логика работы должна быть следующая.
1. Одним запросом загружаете всё из базы
2. Далее в памяти всё так как надо комбинируете
3. Результат либо загружаете в базу сразу, либо если много генерируете скрипт для загрузки и потом его исполняете (можно кусками).
Я не очень по вашему описанию вообще понимаю что вы там и зачем делаете, понимаю только, что путь явно порочный, но скорее всего ничего этого делать не надо вовсе, а надо как-то скрипт так доработать, чтобы при запросе пользователей он и запускался... вызывает большое сомнение, что у вас такой поток пользователей, что эта часть требует серьезной оптимизации.
Обычно, для многих языков есть готовые find/search, которые позволяют находить значения не перебором, в этом направлении следуюет документацию изучить. Но после того, как станет ясно, что "с перебором тормозит". Потому, что может оказаться, что и перебором будет всё работать с достаточной скоростью.
Я признаться вообще не понимаю зачем вам там поиск. Если вы для каждого варианта что-то генерите, генерите последовательно... и всё.
Мощно... т.е. вы не можете найти элемент в массиве, и для этого 100.000 раз гоняете запросы к БД :) ?
Гуглите "поиск элемента в массиве "язык"".
Если речь о массиве из 2000 элементов, то можно попробовать и перебором, всё равно должно быть быстрее чем с БД.
Если массив большой, то придется использовать нормальный поиск (сортировать к примеру, а далее делением пополам)
Если массив огромный, в сотни тысяч-миллионы записей, то тут да - придется использовать БД.
Вы изначально какую-то "муть" делаете... что-то у вас изначально в идее порочное.
Даже если это "заранее прогретый кеш", то непонятно всё-равно зачем к БД с 2000 строк делать 100.000 запросов.
Это не может быть нормальным её использованием.
Если у вас 100.000 инсертов, то яб подумал о том, чтобы генерить скрипт с ними, а затем его исполнять "в одну транзакцию".
(ну или порезать кусками по 10к, смотря как быстрее будет получаться)
Почему не одним скриптом/запросом ? (всё выбрали, все скомпоновали, всё записали)
Или речь о том, что у вас долго отрабатываются 100.000 инсертов ?
Если так - гуглите в сторону отключения на это время индексов, оборачивание в транзакции итп,
но у меня и миллионы без проблем импортируются, и довольно быстро.
Но в целом... "какая-то дичь".
Если хотите это место "кардинально разгрузить", то решением был бы некий демон к nginx-у...
Но, скорее всего, вам это всё не надо вовсе, я как-то сомневаюсь, что у вас сотни тысяч хитов в час...
А что с ней не так через полгода ?
Нормально всё... обычно и через полгода, и через год, и через два. Дальше как повезет....
Может дело в том, "что за винда"... говорят что 90% "сборок" обладают всяческого рода неприятностями... сам не скажу, у меня повсеместно "правая".
