LINUX.ORG.RU

Монолитный Perl и виртуальные машины по 700 Гб оперативной памяти

 


1

4

Добрый день. Подскажите, пожалуйста, ваши рекомендации (мои аргументы как сеньора девопса уже давно закончились). Заказчик имеет виртуальную машину на 700 ГБ оперативной памяти на ферме собственного железа (Proxmox, конечно же, без кластера), внутри которой находится монолитный Perl в 16000+ потоков/процессов, MySQL, KeyDB, Memcached и еще туда сюда. Стартует это всё около 1 часа. Реализация выполнена полностью руками разрабов из разряда «как смогли, так и сделали, ну оно же работает».

Заказчик жалуется, что это работает нестабильно и плохо, подвисает. Да и вообще не хватает памяти и надо больше железа. Проблем он не видит, просто сисадмины не квалифицированные. Которые меняются тут один за одним по очереди, передавая из рук в руки, накопленную гору легаси в виде, описанном выше. Это далеко не самое веселое, что тут имеется.

Посоветуйте, пожалуйста, что мне сказать заказчику почему у него всё работает не как должно?

Перемещено dataman из development



Последнее исправление: dataman (всего исправлений: 3)
Ответ на: комментарий от Iron_Bug

… при разработке под нужды заказчика больше проблем понять, что ему нужно, заложить сверху то,

Всех деталей не знаю, но всё же безусловно он молодец!
Для серии машин M-6000, СМ-1, СМ-2, СТ-2M, была прекрасная документация для системных программистов.
Смотришь исходник драйвера, так в документации по существу все строки детально разъяснены.

Ностальжи.
Разработал возможность многозадачной работы в разделе.

Как?

Разработал:

  • загрузчик (он на лету менял адреса из obj, …);
  • и конечно manager процессов.

Шутка (но это правда).

На Foxpro 2.6 (в те далёкие) разработал ради фана дизассемблер для x86.

… …

Да много чего.

Ныне веду разработку хранилища данных.
Разработчик может задать метаданные объекта (любой сложности и иерархии): таблицы, списки, деревья, … (любой вложенности), а
API предоставляет возможность работы с объектом (не сериализации) в памяти и в файле.

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

Почему всё так?

Знаю цену памяти (не в смысле баксов) и не веду разработку «кто выще бъе, тот краще грает».

anonymous
()
Ответ на: комментарий от Iron_Bug

но примерно всегда можно прикинуть.

Это всё понятно.

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

Соединения с базой данных начинают утекать, из-за этого в проде всё падает.

Всё предусмотреть невозможно.

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

Chiffchaff
()
Ответ на: комментарий от anonymous

Ныне веду разработку хранилища данных.

Чуть позже обязательно подружу линкер с динамическими объектами.
Но это весьма большая тема и нет смысла её пока обсуждать.

anonymous
()
Ответ на: комментарий от Iron_Bug

тогда и железо было слабее

ощущение на самом деле такое, что все наоборот: при сильном желании 10 лет назад можно было собрать утюг из POWER на тысячу ядер, а сейчас довольствуйся PC на пару сотен от силы.

это были серверы Сбера

это те черти же, которым при сбое минут через 5 сказали, что дело в дисковой репликации, а они еще пару недель клиентов мариновали?

borisych ★★★★★
()
Ответ на: комментарий от Chiffchaff

Соединения с базой данных начинают утекать, из-за этого в проде всё падает.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от borisych

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

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

А вообще, это всё про то, что разработка - сложная и непредсказуемая.

Если 10 лет работать в очень узкой области, то наверное, сможешь в ней довольно точно оценивать задачи. Но это редкая ситуация, а у фрилансера - тем более.

Фрилансера ноги кормят: сегодня он пишет cli утилиту, завтра бэкенд, послезавтра - биллинг. Иначе вообще ноги протянет.

Chiffchaff
()
Ответ на: комментарий от Iron_Bug

качество разработки упало. и железо не спасает ситуацию.

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

Поэтому всё чаще: «работать надо, думать некогда», «бери больше, кидай дальше»

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

всё возможно. просто это требует вдумчивого и тщательного планирования. в том числе и системы тестирования.

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от borisych

насчёт «чертей» я не в курсе. я работала в коммерческой компании, которая в своё время писала часть софта для Сбера. Сбер - очень большая компания, у них много серверов, от огромных ЦОДов до мелких отделений в маленких деревнях. ну и так как я по работе иногда имела доступ к разным серверам, то видела в крупных ЦОДах всякое. что касается бизнес-процессов Сбера, то я никогда не была их фанатом (такой совок в обслуживании клиентов ещё поискать надо), поэтому не вникала. наша задача была - сети. вот сетями мы и занимались, в остальное не лезли даже близко.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Chiffchaff

Поэтому всё чаще: «работать надо, думать некогда»

вот этот принцип я никогда не поддерживала и не буду. если я вижу такое, я сразу уйду. это ведёт только к говнокоду и проблемам с его стабильностью и поддержкой.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от borisych

если утром первым пришел толстый клиент, то весь день всем остальным будет плохо, а если наооборот - будет наоборот.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

угу, весь интернет против тебя, а ты стоишь на своем, потому что правильные книжки читал. Нет ли здесь никакой аналогии с докерами, микросервисами и иже с ним?

borisych ★★★★★
()
Ответ на: комментарий от borisych

нет, и даже намёка нет. я не использую «докеры, микросервисы и иже с ним».

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от borisych

и да, мир не против меня. но мир сложен. есть два пути: понять эту сложность, подумать и принять взвешенное решение или спихнуть всё на какой-то чёрный ящик вроде БД, в надежде, что «проканает». во-первых, не всегда проканывает. во-вторых, второй подход требует заведомо больше ресурсов, причём часто критически больше.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от borisych

Ну так обычно в работе нужны витрины в плоском виде, а не сборка из реляций. Потому и не видел. А если накопление структурированных данных - то всё будет по книжке.

Shadow ★★★★★
()
Ответ на: комментарий от Iron_Bug

хотя я тут неправильно написала. не верификация, а версионирование. вот. обработка в зависимости от. это «от» может быть разным и зависит от зания специфики обрабатываемых данных. если разработчик хорошо знаком со спецификой и знает распределение тех или иных запросов, он может существенно оптимизировать обработку потока данных.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

вот этот принцип я никогда не поддерживала и не буду. если я вижу такое, я сразу уйду. это ведёт только к говнокоду и проблемам с его стабильностью и поддержкой.

какой принцип-то? Есть некая объективная реальность, заключающаяся в следующем:

  • что в маке, что в майкрософте, докер на самом деле - это некая довольно ограниченная по возможностям виртуальная машина внутри хоста, там проблемы и с ФС, и с TCP все крайне плохо, и еще непонятно что (на современных маках с ARM еще и реальная виртуализация используется)
  • докер более-менее прозрачно работает только в linux (да и то далеко не факт: могу показать контейнеры, которые запускаются только на определенных версиях хоста), но с учетом 5% на десктопе в мире, в команде более 10% единомышленников ожидать никак не стоит. Вот тут я сталкивался с тем, что кто-то на созвонах на полном серьезе писал текстом, что у него на компе ушаталась альса, поэтому он ничего не слышит и говорить тоже не может… Если ты получаешь деньги за работу и любишь linux, то иди и люби его в виртуальной машине или ночью под одеялом в таком случае, ну либо честно списывай свои трудности в прогулы, а работу надо-таки работать.

т.е. база она на самом деле следующая:

пользователям майкрософт ничего не стоит поставить себе на машину сотню различных версий perl и использовать нужную в каждом проекте или даже бранче, я уже довольно давно не про perl, а про жаву, и у меня совершенно не вызывает проблем установить столько инсталляций, сколько требуется по работе, при этом у меня не будет никаких проблем с дебагом, профилированием и пр. Здесь условный «Я» представляю мнение 90-95% коллег (все тролли могут заранее идти нахер, потому что я уже более 10 лет пользуюсь настоящим юниксом, а не поделкой финского фашика).

Теперь приходит какой-то некомпетентный хрен с совершенно упоротыми идеями, что все плохо только потому что разработичики не используют докер (по факту если в проде специфичное ПО используется, то можно всех заставить сидеть хоть на WinXP, хоть на DOS), а потом плачется, что ему «руководство не позволяет что-то делать», ну бери и делай, только совсем не в то время когда у тебя более важные задачи висят, можешь на выходных сидеть - в случае успеха получишь заслуженные отгулы, ну а в случае неуспеха придется ПСЖ писать, вроде все честно, разве нет?

borisych ★★★★★
()
Ответ на: комментарий от Chiffchaff

вопрос «обгона» тоже философский. если у твоего конкурента софт падучий и глючный, если клиенты теряют данные, пока прод лежит пластом, то это не поможет в продвижении таких решений. а тут ты на белом коне, с надёжным и эффективным софтом. пусть там нет столько свистоперделок, но всё работает стабильно. я думаю, что найдётся немало клиентов, которые предпочтут стабильно работающий софт какому-то непонятному говнокоду.

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Shadow

А если накопление структурированных данных - то всё будет по книжке.

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

borisych ★★★★★
()
Ответ на: комментарий от borisych

какой принцип-то?

вышеописанный, естественно. и я его привела в цитате. не вырывайте из контекста.

«настоящий юникс» был на системах, разработанных Bell Labs и имел архитектуру AT. что сейчас обзывают этим сочетанием, сложно даже представить. из ещё живых остался недодушенный Ораклом SUN, который днём с огнём не сыскать в реальном железе. есть весьма корявый Solaris и его клоны разной степени годности для реального использования. но сам Solaris уныл, по сравнению с возможностями кернела современного Linux. и я имела дело с обоими системами, я это утверждаю вполне осознанно. ещё иногда «юниксом» называют голимую проприетарщину, впариваемую с десятикратной стоимостью под соусом жопсовского пиара. но с точки зрения разработчика она ничем не лучше маздая: такой же чёрный ящик без поддержки и возможности что-либо в нём изменить. так что я не знаю, что там за тру юникс. звучит смешно, на самом деле. я много лет работаю в разработке и пока что Linux меня вполне устраивает. и для моих задач, и по работе.

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

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

вот вы реально в это верите, или кто-то когда-то в уши нассал?

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

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

там у нас в какой-то момент совсем не срослось, потому что меня начали про какие-то нелепые стандарты разработки спрашивать и пр., ну да ладно, история не про это. Буквально недавно (3 месяца назад) я с сыном путешествовал авиакомпанией, у которой на экранах в спинках сидений гордо красовалось: «Powered by Thales», при этом треть сидений просто не работала, там где что-то хотя-бы включалось тупило настолько жутко, что представить невозможно (наш аэерофлот в этом плане похоже впереди планеты всей: к херам все это - подключайся по вафле к нашему медиа-центру и смотри кинохи, с тачками ровно такая же ситуация: там оборудование и сопутствующее ПО устаревает еще до начала сертификации), и вот я гордо рассказывал сыну, что я туда собеседовался и в итоге не пошел, поэтому сиди и терпи теперь.

borisych ★★★★★
()
Ответ на: комментарий от Iron_Bug

вопрос «обгона» тоже философский. если у твоего конкурента софт падучий и глючный, если клиенты теряют данные, пока прод лежит пластом, то это не поможет в продвижении таких решений. а тут ты на белом коне, с надёжным и эффективным софтом. пусть там нет столько свистоперделок, но всё работает стабильно. я думаю, что найдётся немало клиентов, которые предпочтут стабильно работающий софт какому-то непонятному говнокоду.

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

anonymous
()
Ответ на: комментарий от Shadow

MongoDB - помойка!

монга-то тут причем? вот говорим «сотрудник Василий предпочитает, чтобы перед вторым полнолунием в году у него тема UI автоматически переключалась на Dark», Теперь разложите это в 3NF.

borisych ★★★★★
()
Последнее исправление: borisych (всего исправлений: 1)
Ответ на: комментарий от borisych

французские удаки пишут ПО для самолетов на жаве и OpenGL - я такой дикой связки никогда в жизни бы не мог себе представить, но вот бывает

О, французский софт - это отдельная тема для приколов. У них бывают хорошие или плохие вещи, но пишут их явно извращенцы местами =)))

anonymous
()
Ответ на: комментарий от borisych

вот вы реально в это верите, или кто-то когда-то в уши нассал?

что за наезды и оскорбления? может, вам кто-то в уши и «ссыт», и вы по собственному опыту судите других. я не знаю. но я лично искала и нашла предложения такого софта, конкретно для тестирования системы LTE, Camel и прочих при работе на ОПСОСа. и вполне серьёзно рассматривался вариант купить такую систему, поэтому я помню порядки сумм, которые за неё просили. система эмулировала весь поток телекома и позволяла гонять тесты. если бы тогда были чуть более стабильные времена в экономике (если в Эрефии это вообще бывает), то и купили бы. для иностранных компаний это не деньги.

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

совсем непонятно, при чём тут история с провалом вашего собеса куда-то там. абсолютно не показательно.

Iron_Bug ★★★★★
()
Ответ на: комментарий от borisych

Софт стоит дорого, поэтому его оптимизируют по деньгам по разному. За софт который рулит самолетом заплочено(условно - цифры из больной головы) 100$ за строку, а софт мультимедия в салоне, который никак не связан с самолетом и сидит на отдельном сервере и в отдельном контуре 1$ за строку. От этого и результат.

AoD314
()
Ответ на: комментарий от anonymous

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от borisych

… пользователям майкрософт ничего не стоит поставить себе на машину сотню различных версий perl и использовать нужную в

Эту задачу лет двадцать как решить нужно было, а она и ныне не решена …

anonymous
()
Ответ на: комментарий от AoD314

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)

Посоветуйте, пожалуйста, что мне сказать заказчику почему у него всё работает не как должно?

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

anonymous
()
Ответ на: комментарий от Iron_Bug

французы ничем не отличаются от прочих людей, и разработчиков

да, вот оно все так, в России все сплошь и рядом ксенофобы, и поэтому в открытую говорят, что елки, царей зверей и *езды не ремонтируют, а в других странах на таком дерьме просто не ездят, но зато не ксенофобы…

вот вспомнил еще..

была какая-то контора, тоже французская, которая решила делать бизнес на том, что рендерит всякое в PDF, я в их сайт потыкался, оказалось что помимо всего прочего оно еще умеет в PDF рендерить и /etc/passwd и прочие внутренние ресурсы, выложил это у себя в блоге, они чет на меня обиделись и хотели в суд подавать.

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

в целом получается что 3 из 3 и все мимо, совпадение?

borisych ★★★★★
()
Последнее исправление: borisych (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

конкретно для тестирования системы LTE, Camel и прочих при работе на ОПСОСа

вы же понимаете, что ОПСОСы как работодатель на рынке IT стоит где-то на четверть ступеньки выше ритейла, да?

borisych ★★★★★
()
Ответ на: комментарий от borisych

… была какая-то контора, тоже французская, которая решила делать бизнес на том, что рендерит всякое в PDF, я в их сайт потыкался, оказалось что помимо всего прочего оно еще умеет в PDF рендерить и /etc/passwd и прочие внутренние ресурсы,

В NTFS поддержаны потоки https://learn.microsoft.com/ru-ru/windows/win32/fileio/file-streams

Смотришь в shell файл 0 байт, а к нему-то прикреплены скажем два потока по 1GB.

anonymous
()
Ответ на: комментарий от borisych

не понимаю. в чём проблема? у ОПСОСа вполне себе много задач, где можно и нужно применять мозги. большие потоки данных, сложная обработка в риалтайме. я бы сказала, что работа у ОПСОСа напоминает работу у сетевого провайдера, только со спецификой 3GPP стандартов и специфических для телекома протоколов. в остальном - всё то же самое: сети, серверы, потоки данных. и всё должно работать 24/7 и желательно, чтобы быстро и эффективно. и я даже оптимизировала некоторые вещи у ОПСОСа, сделав сервис быстрее и жизнь клиентов немного лучше. это всегда хорошо. не вижу никаких проблем с работой у ОПСОСов. единственное, что меня бы остановило, это принадлежность компании к одиозным олигархам. но я работала на местного провайдера, который совершенно честно заработал себе место под солнцем и это был вполне достойный бизнес.

Iron_Bug ★★★★★
()
Ответ на: комментарий от router

Посмотреть, где и во что упирается, почему запускается час (это ж бред, что-то явно не так) и т.д.

Кэш разогревается, пока эта «гравицапа» вычитывает часть базы для работы?

sanyo1234
()
Ответ на: комментарий от sanyo1234

На производительность чтения почти не повлияет тоже.

Многие СУБД не умеют при чтении использовать более одного индекса, да и не очень это эффективно в любом случае, даже когда БД пытается использовать более, чем один индекс при выполнении запроса. И даже в этом случае, часто требуется переписать запрос, поиграть то с CTE, то с JOIN’ами, то с вынесением в подзапрос.

Оптимизация запросов и БД, это не такая простая штука, что просто пришёл в незнакомый проект, насоздавал индексов, и он залетал.

Как тут некоторые псевдо-гуру пишут.

Chiffchaff
()