Цитата(Jey_k @ 16.11.2004, 07:19)

Мое становление как программиста пришлось на время когда не было кнопочек и прочего и все надо было делать руками. Бессонные ночи, литры выпитого кода, километры сигарет, сон на клавиатуре...

Мы все очень за тебя рады. Но насчёт сигарет - минздрав предупреждает..

Цитата(Jey_k @ 16.11.2004, 07:19)

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

Мне лично пофик (мягко сказано) на таких ламеров.. Я сам когда то был таким, и вроде вырос из того возраста...
Прикольно, я в кружке в 10 лет сделал программу "Нажми кнопку" на VBA и вроде бы начал считать себя программистом

Добавлено @ 18:33

Цитата(Jey_k @ 16.11.2004, 07:19)

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

Ты работал программистом в коммерческой фирме?

Это сообщение отредактировал(а) chipset - 16.11.2004, 18:32

Цитата

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

а я вот "наваять" Xerces или JOGL нe смогу... Времени простo нe хватит. Можеt, каждый раз перед запуском еще и компиляtор переписывaть - для верности?

Цитата(Jey_k @ 16.11.2004, 09:19)

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

Ну и что? Я могу уважать человека если он знает мельчашие детали фосфорилирования алканов, но если мне нужен химик для проведения количественного анализа тояжёлых металлов - то его знания деталей фосфорилирования алканов меня не волнуют... Если мне нужен сейчас (это реально - это именно тот человек которого я ищу) помошник чтобы он помог мне разрабатывать программы для SQL сервера, то мне нужен программист очень хорошо понимающий query-rewrite, детали реализации оптимизатора запросов, а так же все функции DBCC и T-SQL... мало того мне даже наплевать умеет ли он вообще код писать сложнее обычного цикла, и знания алгоритмов от него мне на фиг не нужно.

Цитата(Jey_k @ 16.11.2004, 09:19)

программирование - это перевод математической модели формализованной задачи к исполняемому коду.

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

Цитата(Jey_k @ 16.11.2004, 09:19)

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

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

Вот тебе реальная задача:

Дано: таблица в MS SQL Server 2000 - размер 200 гигабайт, количество полей десяток, количество записей десятки миллионов. Загрузка таблицы - примерно 100 одновременных подключений, выполняется порядка 10 запросов в секунду, из них 30% Update/Delete/Insert, остальные Select возвращающий одну запись:

Select Field1 From Table Where Field2='чего-то там'

Delete могут затрагивать десятки тысяч записей.

Проблема в производительности: сервер подыхает, 100% загрузка 4х мощных процессоров, 100% использование 16 гигабайтов RAM. Что сделать чтобы увеличить производительность?

Цитата(Vit @ 16.11.2004, 07:50)

Дано: таблица в MS SQL Server 2000 - размер 200 гигабайт, количество полей десяток, количество записей десятки миллионов. Загрузка таблицы - примерно 100 одновременных подключений, выполняется порядка 10 запросов в секунду, из них 30% Update/Delete/Insert, остальные Select возвращающий одну запись:

Нифига ж себе... O_O
Добавлено @ 19:03

Цитата(Domestic @ 16.11.2004, 07:50)

Можеt, каждый раз перед запуском еще и компиляtор переписывaть - для верности?

Заодно процессор переделывать...

Цитата(chipset @ 16.11.2004, 09:59)

Нифига ж себе... O_O

Это не много, это обычная производственная база данных среднего размера.

Цитата(chipset @ 16.11.2004, 15:59)

Цитата(Vit @ 16.11.2004, 07:50) Дано: таблица в MS SQL Server 2000 - размер 200 гигабайт, количество полей десяток, количество записей десятки миллионов. Загрузка таблицы - примерно 100 одновременных подключений, выполняется порядка 10 запросов в секунду, из них 30% Update/Delete/Insert, остальные Select возвращающий одну запись: Нифига ж себе... O_O ...

Да ладно, нормальная база.
Это ж не школьная библиотека.

Цитата(Vit @ 16.11.2004, 15:50)

Дано: таблица в MS SQL Server 2000 -  размер 200 гигабайт, ... ... Что сделать чтобы увеличить производительность?

Переписать код доступа к файлам базы данных, так как он видимо реализован неоптимально в MSSQL. А еще лучше, реализовать свой более эффективный формат данных с самыми эффективными алгоритмами доступа

Цитата(Sun @ 16.11.2004, 10:42)

Переписать код доступа к файлам базы данных, так как он видимо реализован неоптимально в MSSQL

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

Цитата(Vit @ 16.11.2004, 21:48)

например разбив таблицу на несколько и более мелких

Декомпозиция?
Вообще неплохо бы еще дерево разбора команд забацать, установить их приоритеты.
Есть такая наука "Теория массового обслуживания", проходили на 4-м курсе.
Согласно ее можно предложить следующее:

Код

_буфер_   -->[|||]-->|----------------------|-->{команда_тип_1}-->|приоритет_1| -->[|||]-->|Семантический селектор|-->{команда_тип_2}-->|приоритет_2|------> выполнение -->[|||]-->|                      |-->{.............}-->|...........| -->[|||]-->|______________________|-->{команда_тип_n}-->|приоритет_n|

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

Это сообщение отредактировал(а) Jey_k - 16.11.2004, 23:45

Цитата(Jey_k @ 16.11.2004, 14:38)

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

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



Добавлено @ 00:26

Цитата(Jey_k @ 16.11.2004, 14:38)

Декомпозиция?

Нет не декомпозиция, просто реорганизация с учётом скоростей выполнения различных процессов...
Добавлено @ 00:27

Цитата(Sun @ 16.11.2004, 10:42)

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

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

Думается мне, что на размер 200 гигабайт уже лучше ставить Оракул (хотя на 4 проца это лишних ~80000$), но там и с индексами дела обстоят лучше.....

Jey_k, а где ты планируешь размешать свой селектор? На сервере? Ну так он вообще сдохнет


Это сообщение отредактировал(а) stron - 17.11.2004, 01:08

Цитата(Vit @ 17.11.2004, 00:24)

Массовым обслуживанием тут и не пахнет

То есть как? Это же классический ее пример, продажа билетов и прочего.

Насчет селектора. Его бы неплохо отдельным аппаратным решением обозначить. Компом например.
И еще... Там один сервер?
Вообще такие задачи выполняются подсетями. Одна машина если и выдержит такой поток данных, то только имея процессоров 16 ИМХО.
А вообще балансирование на пороге стрессовой интенсивности работы чревато чем?
Правильно! DOS,DDOS. А для такого серьезного предприятия, которое опереирует деньгами и билетами это ой как чревато.

Собственно по решению задачи мои предложения:

-Ставим подсеть. 3 серва, к примеру,
-Несколько компов как селекторы
-Фильтруем запросы и распределяем по несущим машинам

По идее скорость возрастет, при наличии хорошего канала.
Я подниму свой конспект по ТМО и поищу похожую задачу, может помогу чем.

Цитата(Vit @ 16.11.2004, 18:50)

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

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

Цитата(Jey_k @ 17.11.2004, 04:44)

Да хоть 300 лет пройдет суть от этого не поменяется.

Не согласен Jey_k. Нельзя все гребсти под одну гребенку. Все зависит от специализации. Если ты расчитываешь ядерный синтез, то твои слова актуальны. Если же ты выполняешь заказ, на создание какого-либо автоматизированного рабочего места (АРМ) (90% написанных на сегодня программ), то я сомнвеваюсь, что в процессе реализации возникнет необходимость применять высшую математику, и какие-то сложные алгоритмы.

Цитата(Jey_k @ 17.11.2004, 01:44)

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

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

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

Сейчас же компы дешёвые, а сертифицированые опытные спецы - дороги и привередливы. Поэтому эффективо надо использовать уже их, а не компы. Современные среды, платформы, тонны библиотек, да и сам ООП-подход строится теперь на ориентации не столько на удобство выполнения этой программы аппаратной частью, сколько на прозрачность, бесперебойную работу и лёгкость в обслуживании. Т.е. программмирование, грубо говоря, как избушка бабы Яги из сказки, повернулось лицом у программистам, а к машине задом - и лучшее тому свидейтельство - возникновение виртуальных машин .NET Framework и JVM. Фактически, они - переводчики бизнес-логики полускомпилированных приложений для низкоуровневых аппаратных средств. Теперь нас это уже практически не волнует.

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

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

Я вдоволь наобщался в своё время с гордыми С++ программистами, которые хвастаются тем, какие лаконичные и строгие, (практически идеальные!) алгоритмы они умеют писать, вот только с тем, чтобы быстро сделать что-то реально нужное в бизнесе у них у всех возникали большие проблемы. Максимум, что они могут - это писать вирусы или антивирусы. А эта профессия никогда не будет массово-востребованной... Даже для современых игрушек важнее реалзация логики сценария, а не движок, который пишут сравнительно небольшими коллективами штучных высококлассных узких специалистов.

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

Это сообщение отредактировал(а) Се ля ви - 17.11.2004, 02:54