форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
Сообщение от opennews (??) on 11-Май-09, 23:13
Новая поисковая технология Microsoft Kumo, идущая на смену Live Search,  базируется (http://news.cnet.com/8301-13505_3-10235400-16.html) на open source компонентах, созданных в рамках проекта по разработке свободной поисковой системы Apache Lucene (http://lucene.apache.org/). Для хранения и обработки данных в Kumo используется Hadoop (http://hadoop.apache.org/core/) (напоминающая Google BigTable система для организации распределенных вычислений с использованием парадигмы map/reduce) и распределенная файловая система HDFS (Hadoop Distributed Filesystem). Hadoop распространяется под лицензией Apache 2.0, т.е. не обязывает раскрывать изменения кода. URL: http://news.cnet.com/8301-13505_3-10235400-16.html Новость: http://www.opennet.me/opennews/art.shtml?num=21689
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
Сообщение от Александр (??) on 11-Май-09, 23:13
Имеют полное право. Спонсоры как никак.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		–1 +/–
	Сообщение от fog on 12-Май-09, 00:03
	Эта ... а свои программисты в Microsoft есть?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+1 +/–
	Сообщение от Аноним (??) on 12-Май-09, 01:20
	это можно сказать в адрес любого, кто берет что-то чужое. Вот Ubunta на ядре Linux'а. Значит в Каноникал нет своих программистов?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от Аноним (??) on 12-Май-09, 12:52
	А это и есть их программисты. Microsoft является платиновым спонсором Apache foundation.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от User294 (??) on 12-Май-09, 21:26
	>Имеют полное право. Спонсоры как никак. Угу, конечно.В итоге как всегда выигрывает один микрософт а остальные сосут болт.Замечательно - так держать, даешь проприетарщину назад в массы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+1 +/–
Сообщение от Аноним (??) on 11-Май-09, 23:20
Понятно тогда, почему разработчики OpenBSD остались на Апаче версии 1.3 из-за лицензии. :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от ононим on 11-Май-09, 23:25
	>Понятно тогда, почему разработчики OpenBSD остались на Апаче версии 1.3 из-за лицензии. >:) а какая лицензия у apache 1.3? да и причем тут OpenBSD? она тоже позволяет код закрыть, как и апач.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		–1 +/–
	Сообщение от User294 (??) on 12-Май-09, 07:56
	>Понятно тогда, почему разработчики OpenBSD остались на Апаче версии 1.3 из-за лицензии. >:) А что, лицензия OpenBSD обязывает некрофильствовать? oO Ужас какой.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		–2 +/–
	Сообщение от iZEN (ok) on 12-Май-09, 08:29
	>Понятно тогда, почему разработчики OpenBSD остались на Апаче версии 1.3 из-за лицензии. >:) Просто Apache 1.3 для однопроцессорных систем и не поддерживает SMP. В OpenBSD по сути инфраструктура поддержки исполнения на многоядерных процессорах (SMP) не развита, так что Apache 1.3 в самый раз. Вот, Apache 2.x использует преимущества SMP-архитектуры.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		–1 +/–
	Сообщение от uldus (ok) on 12-Май-09, 09:11
	>Просто Apache 1.3 для однопроцессорных систем и не поддерживает SMP. В OpenBSD >по сути инфраструктура поддержки исполнения на многоядерных процессорах (SMP) не развита, >так что Apache 1.3 в самый раз. Чего-чего ? Apache 1.3, как и любое приложение параллельно обрабатывающие запросы несколькими процессами, все преимущества SMP задействует. >Вот, Apache 2.x использует преимущества SMP-архитектуры. Тем что 5 лет mod_php для мультитредового worker MPM  допиливали ? До сих пор в продакшин кроме  prefork MPM что-то использовать не рекомендуется, что делает логику работы с процессами Apache2 аналогичной Apache 1.3.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от old on 12-Май-09, 09:19
	Бред. Apache 2 использует потоки, а Apache 1.3 - нет. Вместо этого он запускает отдельные процессы для соединений. и оба используют ipc для межпроцессного взаимодействия. И честного говоря, ещё не известно, что лучше. Зависит от задач.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от iZEN (ok) on 12-Май-09, 09:32
	>Бред. Apache 2 использует потоки, а Apache 1.3 - нет. >Вместо этого он запускает отдельные процессы для соединений. и оба используют ipc >для межпроцессного взаимодействия. Ну я это и имел в виду, когда говорил, что Apache 1.3 не поддерживает SMP. Согласитесь, что потоки от процессов отличаются очень даже. Хотя для *nix стоимость создания нового процесса не так велика, как в Windows, например. >И честного говоря, ещё не известно, что лучше. Зависит от задач. Потоки используют общее адресное пространство (но разные стеки). Процессы имеют каждый собственное адресное пространство и изолированы друг от друга, используют IPC для обмена данными.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от Zz on 12-Май-09, 09:45
	>>Бред. Apache 2 использует потоки, а Apache 1.3 - нет. >>Вместо этого он запускает отдельные процессы для соединений. и оба используют ipc >>для межпроцессного взаимодействия. > >Ну я это и имел в виду, когда говорил, что Apache 1.3 >не поддерживает SMP. Согласитесь, что потоки от процессов отличаются очень даже. >Хотя для *nix стоимость создания нового процесса не так велика, как >в Windows, например. Вы, наверное, не в курсе, что для обработки нового запроса _не_ создается новый процесс, так что стоимость создания нового процесса не играет существенной роли, поскольку создание новых процессов происходит сравнительно нечасто. Так что, хотя и согласимся, что потоки от процессов отличаются,  но нисколько не согласимся что апача 1.3 не поддерживает SMP. > >>И честного говоря, ещё не известно, что лучше. Зависит от задач. > >Потоки используют общее адресное пространство (но разные стеки). Процессы имеют каждый собственное >адресное пространство и изолированы друг от друга, используют IPC для обмена >данными.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от iZEN (ok) on 12-Май-09, 10:37
	>Вы, наверное, не в курсе, что для обработки нового запроса _не_ создается >новый процесс, так что стоимость создания нового процесса не играет существенной >роли, поскольку создание новых процессов происходит сравнительно нечасто. Всегда думал, что Apache 1.3 на каждый запрос, особенно если это касается mod_php и mod_perl, создаёт новый процесс выполнения или берёт свободный из пула уже запущенных процессов для выполнения запрашиваемой задачи. >Так что, хотя >и согласимся, что потоки от процессов отличаются,  но нисколько не >согласимся что апача 1.3 не поддерживает SMP. Ну да, заместо распределения потоков по ядрам, Apache 1.3 тупо исполняет всё в одном процессе/потоке на одном ядре -- об SMP он не в курсах -- заместо него думает шедулер операционной системы, как правильно раскидать его порождённые процессы/потоки по ядрам.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от Аноним (??) on 12-Май-09, 13:11
	>Всегда думал, что Apache 1.3 на каждый запрос, особенно если это касается >mod_php и mod_perl, создаёт новый процесс выполнения или берёт свободный из >пула уже запущенных процессов для выполнения запрашиваемой задачи. Ага. И как раз бОльшая часть попадает во второй случай. >Ну да, заместо распределения потоков по ядрам, Apache 1.3 тупо исполняет всё >в одном процессе/потоке на одном ядре -- об SMP он не >в курсах -- заместо него думает шедулер операционной системы, как правильно >раскидать его порождённые процессы/потоки по ядрам. Т.е. апач2 сам распределяет потоки по ядрам заменяя собой шедулер ? До чего техника дошла.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от iZEN (ok) on 12-Май-09, 13:45
	>Т.е. апач2 сам распределяет потоки по ядрам заменяя собой шедулер ? До >чего техника дошла. Нет. Его дело порождать потоки и управлять пулом потоков. А распределением ресурсов, например, под потоки в FreeBSD занимаются библиотека libthr и шедулер ULE3.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от Хелагар (ok) on 12-Май-09, 14:20
	>>Т.е. апач2 сам распределяет потоки по ядрам заменяя собой шедулер ? До >>чего техника дошла. > >Нет. Его дело порождать потоки и управлять пулом потоков. А распределением ресурсов, >например, под потоки в FreeBSD занимаются библиотека libthr и шедулер ULE3. > Итого и в том и в другом случае ресурсами управляет ядро ОС. Т.е. разница только в некотором снижении нагрузки на систему ценой (теоретического) понижения надёжности из-за использования общей памяти потоками.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от frewq on 12-Май-09, 16:38
	А давно ULE3 появился ? В 7-STABLE & 8-CURRENT насколько помню ULE2.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от iZEN (ok) on 12-Май-09, 17:10
	>А давно ULE3 появился ? В 7-STABLE & 8-CURRENT насколько помню ULE2. Оригинальная работа ULE основывается на планировщике O(1) Инго Молнара. Он был экспериментальным и остался в ветке 5.x и до сих пор в 6.x. ULE3 был разработан Джефом Робертсоном специально для FreeBSD 7.0. Однако в конфигурационном файле ядра получил то же имя -- SCHED_ULE, что и предыдущая версия экспериментального планировщика -- имя осталось, а код полностью переписан. Предупреждение. Do NOT use ULE on 6.x.  ULE has been revamped heavily on 7.0 and the version on 6.x is old, and is known to contain some bugs. Use it in 6.x if you dare, just don't complain to us if it breaks your system :-) i.e. if at any point you start experiencing problems, do not report them until you have verified that they persist with 4BSD also. "И всё равно, кажный раз отряд леммингов пытается воткнуть ULE на 6.x и взлететь :)" http://www.opennet.me/openforum/vsluhforumID3/40080.html#9
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от User294 (??) on 12-Май-09, 21:57
	>Ага. И как раз бОльшая часть попадает во второй случай. Ага.Здорово получается когда на такой сервак (вы ведь про префорк?) заходят тулзой типа http_load'а.А 1000 постоянно форкающихся процессов вас не напряжет?Ну или остальные юзеры подождут пока мои 1000 реквестов пул процессов отработает, а я тем временем еще 1000 пришлю. Впрочем чаще на мало-мальски популярный сервак однажды просто забредает ботнет какого-нить кульхаксора (мало ли там чего, может админ его сдуру забанил, нахамил, или там еще что а у хакеришки карманный ботнетец на пару тыщ машин как раз имелся).И даже при минимальном числе ботов такое легко кладет апача на лопатки.Нет, не выжрав бандвиз.А просто нафоркав процессов(если админ не выставил лимити адекватно возможностям машины).Или (если админ не дятел и выставил лимиты вменяемо) - просто выюзав в хлам пул процессов, так что легитимные юзеры видят только постоянные таймауты не дождавшись пока процесс им внимание вместо ботов уделит.Это ессно про идиотский prefork.Который конечно в теории то масштабируется по многопроцессорным системам, но чтобы он хорошо масштабировался на практике - надо купить под него никак не менее Крэя, вот тогда наверное смасштабируется. А тот же лайт или нжынкс на аналогичной нагрузке и не бог весть какой машине - вообще не поперхнутся например в случае статики(а апач с префорком и на статику форкается, фигле).В итоге апач с префорком для отдачи статики - просто мечта мазохиста: головняк админу будет обеспечен при минимальной затрате усилий юзеров\хацкеров :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от iZEN (ok) on 13-Май-09, 01:41
	>Впрочем чаще на мало-мальски популярный сервак однажды просто забредает ботнет какого-нить кульхаксора >(мало ли там чего, может админ его сдуру забанил, нахамил, или >там еще что а у хакеришки карманный ботнетец на пару тыщ >машин как раз имелся).И даже при минимальном числе ботов такое легко >кладет апача на лопатки.Нет, не выжрав бандвиз.А просто нафоркав процессов(если админ >не выставил лимити адекватно возможностям машины).Или (если админ не дятел и >выставил лимиты вменяемо) - просто выюзав в хлам пул процессов, так >что легитимные юзеры видят только постоянные таймауты не дождавшись пока процесс >им внимание вместо ботов уделит. Такую ситуацию должен отслеживать нормальный файервол/пакетный фильтр и банить на время "отстоя" адреса, с которых производится DDoS-атака. Не позволять с одного IP-адреса делать реконнекты больше чем с определённой частотой -- святая обязанность файервола.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от User294 (??) on 13-Май-09, 02:35
	> Такую ситуацию должен отслеживать нормальный файервол/пакетный фильтр Ну, ладно, меня одного с http_load забанить можно(и то, только если я не буду засранцем и не размажу это безобразие через жирный прокси-лист, что при желании сделать не вопрос).А вот что с ботами делать которые ведут себя реалистично, подобно юзерам?Попытка бана приведет к бану и легитимных юзеров если атака мало-мальски грамотная.Собственно несколько тыщ ботов и качать неторопливо файлики пожирнее.Как юзеры.Фигли.При этом каждому боту совсем не обязательно часто делать запросы-ему достаточно меееедленно выкачивать толстый файл полчаса.Заняв на полчаса под бесполезную деятельность целый увесистый процесс.В итоге или апач с префорком убьет все вокруг своими кучами процессов или же если урезать пул процессов до вменяемой величины - легитимные юзеры будут дооооолго ждать своей очереди(пока боты по полчаса медленно качают файл, сделав всего 1 запрос...).В итоге браузер им просто покажет табличку рассказывающую про то что connection timed out или они сами задолбутся ждать. Это так, по мотивам виденных атак на реальные апачи в их более-менее дефолтном виде, т.е. дурной prefork.В итоге или апач кладет систему (клинч от тысяч процессов такой что по ssh порой не пробиться, ресурсов проца не хватает) или сайт почти перестает обслуживать юзеров хотя ресурсы вроде как есть(просто пул процессов озадачен левизной а юзерам-фига!). > обязанность файервола. От именно DDoS, даже весьма легкого, силами школоты - не спасет.Потому как индивидуальные боты в случае заточки атаки против именно апача с его префорком не обязаны часто делать запросы: количеством и медленностью скачки возьмут.И пока все воркеры будут по полчаса отдавать файлики ботам, юзеры, разумеется, подождут.А куда они денутся если всех воркеров на полчаса застолбили боты?А через полчаса можно другой файлик покачать.Еще полчаса.Реальные юзеры могут качать даже чаще.Их - в бан? =) А уж вполне легитимный NAT какого-нибудь праводера с кучей юзеров за ним при случае накроет только в путь, если они потопают всей кучкой смотреть "а что это там такое?".А прописывать в исключения все NATы и т.п. - заколебешься. В итоге имхо проще поставить лайт или нжинкс, им на такой тип нагрузки - класть с прибором, расход ресурсов на малоактивные соединения - невелик и уронить становится куда труднее (каналы у серваков обычно толстые и забить их шибко сложнее чем просто поставить апач с префорком в позу).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от old on 13-Май-09, 13:57
	>>Бред. Apache 2 использует потоки, а Apache 1.3 - нет. >>Вместо этого он запускает отдельные процессы для соединений. и оба используют ipc >>для межпроцессного взаимодействия. >Ну я это и имел в виду, когда говорил, что Apache 1.3 не поддерживает SMP. и в каком именно месте? 1. как бы процессы более подходят для SMP, чем потоки (например, перекидывать потоки с их общим адресным пространством между разными CPU более накладно) 2. IPC - вполне себе оптимизирован для подобных задач. да и пишется он уж точно не прикладными программистами. к тому же обе эти версии апача всё-равно вынуждены поддерживать ipc. а чуть меньшее время создания процесса компенсируется созданием пулов процессов, что требует минимального планирования и не более.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от old on 13-Май-09, 13:58
	сори s/а чуть меньшее время создания процесса/а чуть меньшее время создания потока/
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от Аноним (??) on 15-Май-09, 15:54
	Адресное пространство самой программы и её копий (сегменты text) в linux и BSD будет общее, да и часть сегментов DATA тоже, если только программа не будет в них производить запись.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

33. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
Сообщение от Zenitur on 13-Май-09, 14:33
Если Майкрософт станет делать свободное и открытое ПО, это будет... неправильно!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Поисковая технология Microsoft Kumo использует компоненты Ap..."		+/–
	Сообщение от аноним on 13-Май-09, 14:36
	>Если Майкрософт станет делать свободное и открытое ПО, это будет... неправильно! ох, и не говорите
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]