×Закрыть

PHP программист в handmade-стартап Mash.ua — йиииха, растём!

Mash.ua — это самая крупная в Украине площадка для продажи и покупки ручной работы (около 30.000 уникальных товаров, 3.500 студий и мастеров).

Это хороший, годный и уже проинвестированный стартап.

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

Оплата: з/п + процент

Обязательно: PHP, MySQL, nginx, Symfony2, Twig, Doctrine 2

Желательно: опыт UNIX / Linux администрирования, Mercurial, Memcached

Камон к нам за деньгами и приключениями!

Расскажу, объясню, уточню: kate@mash.ua

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Хотел купить вязанного зайца, кнопка не нажимается... срочно нанимайте програмиста

«годный стартап» :-)

у меня впечатление что вы хотите кого то на dev ops позицию но почему то избегаете этого слова в описании вакансии :З

Пхп девелопер с опытом администрирования Linux? Если человек пхп девелопер, то весь его опыт в администрировании - убунта на локалхосте.... Если больше, то он и админ херовый и девелопер. Ибо хороший админ не будет на php программировать. Хотябы из принципа :)

А чем вообще админы занимаются в век облачных технологий?

Пишут на руби рецепты для деплоя через шеф?)

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

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

А уж как вы называете «чувака, который следит за серверами» — не есть суть важно.

«облако» это та же виртуализация. Просто новое модное слово и дороже :). Эти «облачные сервера» всегда нужно настраивать. Дабы не попадать на бабло при повышенной СPU и IO активности, коих можно было избежать настройкой. Плюс не всегда «облако» есть выход. Для нагруженных проектов «облако» зачастую не подходит из-за показателя стоимости и качества

Сколько пафоса, нагруженные проекты, что именно ты настраиваешь на твоих серваках что бы «не попадать на бабло при повышенной СPU и IO активности»?

где ты пафос увидел ? о_О. Относительно нагруженных проектов — так все к этому стремяться. Нагрузки, пользователи, клики. все же именно туда идут. Именно там веб-проект начинает приносить деньги. Так что о больших нагрузках нужно думать всем. Кроме тех, кто не хочет расти.
Раз мы так на ты, то Ты когда нибудь изучал дефолтовый конфиг mysql ?
Он создан, чтобы отчаянно крутить винтом .... А знаешь какие оптимальные настройки mysql? Нет таких. Онизависят от структуры, обьемов БД и типу запросов к ней.
Apache тоже тюнится и по скорости работы и по коричеству используемой памяти. И так кадый софт, ОС.
Админ должен быть. :)

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

P.S. не забываем, что реально тонко тюнить нужно далеко не каждый сервак. В большинстве случаев «советов из гугла» и смекалки хватит с головой.

чтобы советы из гугла применять, нужны какието знания.
Мы сейчас админа ищем себе в команду. Скромные требования, хорошая ЗП. www.work.ua/jobs/736811. Но только 5% из приходящих могут дать точное определение что такое LA, в чем оно меряется и что будет, если на сервере закончилась память.
И это «админы» с несколькими годами стажа .. и кто то им платит уже сейчас ....
я это к чему, считаю, что Вы счастливый человек, если знаете ребят,

весьма успешно работающих на стыке программирование/администрирование
.
Но только 5% из приходящих могут дать точное определение что такое LA
Может потому что LA на современных многопроцессорных многоядерных системах — это часто полная фигня? :)
кстати, зоопарк у вас странный — фря, гента... я таким страдал лет...мм.. 6 назад. Сколько десятых процента производительности выжали, собирая из портов? :) а сколько времени потратили в поисках человека, которому хочется с этим возиться?

С какой это радости ? Современные сервера работают по другому, нежели 10 лет назад? Или Вам непривычно осознавать что LA 25 — 64 абсолютно нормальный показатель?(в зависимости от количества ядер конечноже)

У вас в вакансии про воип тоже упомянуто — хорошо воипу живется при LA 64 (допустим, что включен транскодинг)?

Вы чисто технически интересуетесь? Тогда проведите тесты.
А если увидели знакомые слова в вакансии и в моих ответах, после чего решили их почемуто связать вместе и задать каверзный вопрос — не нужно.
Притом вы ставите задачу очень расплывчато.
«хорошо воипу» — это как?
Если на сервере 128 процессоров, то ему очень хорошо. Если 12 — то не очень.. :) Да и памяти должно быть, чтобы не свопило.

А если увидели знакомые слова в вакансии и в моих ответах, после чего решили их почемуто связать вместе и задать каверзный вопрос — не нужно.
Максимально-допустимые значения LA могут в разы различаться в зависимости от задач, возложенных на сервер, поэтому отсеивать соискателей по знанию, в чем оно измеряется — это немного странно :)

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

Без этого понимания просто невозможно определить допустимое это LA или нет.
Ну и как понимание, что это процессы в очереди на исполнение — поможет админу определить, допустимое сейчас значение LA или нет? :D Эти «попугаи» ничем не лучше попугаев в синтетических тестах. Вроде что-то конкретное значат, а на деле — зависит исключительно от конфигурации сервера и возлогаемых на него задач. И важнее понимание того, каким должен быть LA для конкретного сервера, а не в чем он измеряется. Вы все равно ему потом объясните, мол этот сервер занимается отложенной обработкой таких-то данных, тут LA в 64 — это норма. А эти сервера занимаются стримингом, тут LA должен быть не более 1.2 * CoresCount....

та так, что если он думает о LA как о попугаях — то как он что то вообще может по нему определить ? Что рассказать админу мы и так найдем. Но фундаментальные вещи, как устроена ОС, как она работает с памятью, чем тридинг от форкинга отличается — нужно понимать. Если у человека 3 года опыта, а он в этом не разобрался, то это ленивый, конченый человек. Который все что может — советы с хабры копипастить, с надеждой, а вдруг поможет.
Хабраспециалист блин а не админ.

благодаря AWS и подобным спрос на linux-админов упал, конечно. Наверное, теперь можно вот так «харчами» перебирать :) Те знакомые админы, кто хорошо срединг от форкинга отличает — работают за ЗП минимум в 2 раза больше вами озвученной.. может им повезло, конечно :)

Повезло тем, кто не знает и получает $1.5к — ото точно повезло :)

Те знакомые админы, кто хорошо срединг от форкинга отличает — работают за ЗП минимум в 2 раза больше вами озвученной..
Охеренно сокровенное знание.

Не сокровенное, просто для многих админов не первой необходимости.

Я тогда не понял зачем за это в два раза зп накидывают?

Накидывают за знания всеговсего, в тч и этого.

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

именно за лишние и не нужно доплачивать

хм...а что по вашему первой необходимости ?
Это же из области базовых знаний о системе....
Вот ставит такой админ Apache. И как ему выбрать, prefork или worker ? Наугад ? :)
Наугад — это как-бы больше для рисования нежели администрирования :)

LA не очень хорошо отражает реальную ситуацию на системах, поддерживающих виртуализацию. Я просто приведу пример.
uptime
2:07pm up 115 day(s), 14:36, 4 users, load average: 19.91, 16.25, 12.97
psrinfo -vp
The physical processor has 64 virtual processors (0-63)
SPARC-T4 (chipid 0, clock 2848 MHz)
The physical processor has 64 virtual processors (64-127)
SPARC-T4 (chipid 1, clock 2848 MHz)
...........................................................
CPU states: 79.0% idle, 15.0% user, 6.0% kernel
--------------
Это на одной из зон, где все пока что тихо.
Как только где-то начинается шось нехорошее, загрузка ядра растет, LA растет везде.

З.Ы. Я не админ

Эти ребятки получают 20-24к гривен (т.е. вдвое больше того, что вы предлагаете). Вы всё ещё удивляетесь, почему такие как они вам не звонят?

P.S. 5% ? Чтобы сделать такой вывод, надо опросить хотябы человек 40. Это ж дофига работы. Не проще ли было уже отдать администрирование на аутсорс?

P.P.S Кстати, как мне подсказывают «досвидчени» товарищи, искать хорошего админа надо на 2к+ долларов

там очень большие требования ? LАMP ! это вдруг стало так тяжело ? У нас работает админ и получает $2к. пришел на $1к полтора года назад. Знаний вразы больше было нежели у тех, кого мы видим сейчас. 300 резюме, что нам приходили и с кого мы собеседовали. Некоторых лично, некоторых по телефону. Может 40 человек и небыло. Но то что больше 20 то точно. Остальные не подходили на уровне резюме . Это кстати нифига не сложно. просто время надо.

P.S. Мы и есть аутсорс админов.

дефолтовый конфиг mysql ?
Он создан, чтобы отчаянно крутить винтом
А расскажи какие именно улучшения ты делаешь что бы не заставлять мскл крутить винтом?

Если в двух словах, то основная тема — подтянуть данные в память. Запись всеравно на диск, а вот читать лучше с памяти.
Кеш ключей для myisam, буфер innodb, кеш запросов.
Также размеры временных таблиц, чтобы они в памяти создавались. Если все же программисты пишут запросы с сортировкой на диске — то RAM диск для временных таблиц.
Также следует обратить внимание на то, какие и куда бинлоги пишутся, если они вообще нужны.
В innodb есть много переменных, которые могут улучшить ситуацию.
Например метод сброса логов при коммите, при каждом или раз в секунду.
И тд.

Если в двух словах, то основная тема — подтянуть данные в память.
Данные и так подтягиваются в кеш ФС, и куча БД это использует, вроде монгодб(где вообще нету никаких кешей), кассандры(где рекомендуют отдавать под служебные нужды не больше 25% памяти), а то что ты делаешь приводит к обратному эффекту, потому что у тебя данные дублируются, в кеше ФС и кеше БД, и соответсвенно в память помещается меньше. Учил бы матчасть прежде чем пафосничать.

Есть подозрение, что кеш СУБД несколько производительнее будет, чем кеш ФС, за счёт работы с родными типами данных, а не файлами (пусть и в оперативке). Так что я думаю, есть некое оптимальное соотношение.

Ну а вообще, круто было бы глянуть на прирост производительности после тонкого тюнинга (при условии что первоначально СУБД сконфигурированна по советам из гугла).

Есть подозрение
Есть такое подозрение, но оно совершенно не релевантно «подтягиванию данных в память».

Ну дык — админ :). Всё таки лучший результат, это если админ-программист обьеденяют усилия, и выдают на-гора совместный продукт оптимизации, а не «закидывают данные в память»

Это 100%, без налаженной комуникации и админы <=> программисты вообще никак.
Но данные в память всеравно прийдется закидывать, так дешевле :)

Но данные в память всеравно прийдется закидывать

Да это понятно, весь вопрос в том, какие данные и в какую память. Особенно, если мы говорим об облаке/ферме

Кэш СУБД работает гораздо производительнее при условии отключении кэша ФС, т.е. монтировании файловой системы с опцией forcedirectio или что там разрешается на конкретной ФС.
Запись в файлы и журналирование работает намного быстрее в случае если асинхронный ввод-вывод возможен.
Но это уже очень специфично для ОС, ФС и СУБД.
Прирост производительности может варьироваться в широких пределах.

З.Ы. я не админ)

Чего только в этих линуксах не встретишь...
«The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances.» © Linus T
Надо отметить, что большинство файловых утилит по умолчанию работают с очень небольшим размером блока ввода-вывода, что может замедлить работу стандартных файловых утилит в отсутствии файлового кэша.

Кэш СУБД работает гораздо производительнее при условии отключении кэша ФС, т.е. монтировании файловой системы с опцией forcedirectio или что там разрешается на конкретной ФС.
Прям какой то топик вредных советов. Ты реально видел что бы кто-то так делал?

Короткий ответ — да. Я сам так делаю
Нужен длинный ответ?

Дополню свой ответ. Подразумевается, что кэш СУБД разделяемый, т.е. данные, загружаемые туда, кэшируются для всех пользователей. Если в рамках каждого серверного процесса создается свой «собственный» кэш, то никакого выигрыша не будет, конечно выигрыш сомнителен.

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

Я сейчас бенчмарк показывать не готов.
Самый лучший и убедительный бенчмарк может быть получен на сравнении и прогоне какого-нибудь эталонного теста на файлах данных, созданных на файловой системе и файлах данных, созданных на «сырых» устройствах (raw devices). В этом случае обходится наибольшая часть «лишнего» кода в ядре.
У меня на это нет времени. Могу только сказать, что в те далекие времена, когда прямой доступ не был доступен на файловых системах, простой перенос файлов данных на сырые устройства давал прирост в общей производительности ввода-вывода до 10%, а там где возникали проблемы и ожидания, до 30%.
Ссылки по теме.
www.solarisinternals.com/....php/Direct_I/O
www.ibm.com/...1204concurrent
www.toadworld.com/....direct-io.aspx
pic.dhe.ibm.com/..._admin_0569.htm
И... внимание! Firebird!
Правда, тут непонятно. Из форума не совсем ясно действительно ли правильным образом реализована поддержка прямого ввода-вывода в ядре СУБД и дает ли это выигрыш.
tech.groups.yahoo.com/.../message/113376
PostgreSQL не поддерживает ни сырые устройства, ни прямой ввод-вывод на файлах данных, только на журналах.
grokbase.com/...-device-support

Простые тесты с dd не дают оценить реальной выгоды для СУБД.
alexb@XXX:~$ dd if=/dev/zero of=./test.tmp bs=4M count=300 conv=notrunc oflag=direct
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 24.3632 s, 51.6 MB/s
alexb@XXX:~$ dd if=/dev/zero of=./test.tmp bs=4M count=300 conv=notrunc
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 30.9162 s, 40.7 MB/s
alexb@XXX:~$ dd if=/dev/zero of=./test.tmp bs=4M count=300 conv=notrunc oflag=direct
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 24.4824 s, 51.4 MB/s

Т.е. выставляя forcedirectio ты действуешь в слепую? Я правильно понимаю?

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

Ссылки читал?
Все нечитал. Какую из нужно почитать?

Ну как бы там, в основном, ссылки на документацию разных СУБД.
ОК, вот еще хорошая ссылка.
kevinclosson.wordpress.com/...ranged-monkeys

Ну все твои ссылки после беглого взгляда (уж извини, детально читать некогда, нужно Головача троллить), либо пространные вроде «но может дать прирост, а может и не дать», либо иррелевантны БД, как последняя например.

Ну ок. Мое дело показать, твое дело — не согласиться.
Последняя ссылка намекает на ограничения функций стандартного буферизованного ввода-вывода и на то, как их можно обойти, используя прямой ввод-вывод.
kevinclosson.wordpress.com/...with-direct-io
Из этой ссылки цитата:
I encountered this with a customer complaining about the time it was taking them to do a backup and suspecting something was wrong with the tape subsystem. Of course, running a few very simple tests, like reading from /dev/zero and writing to tape (perfectly compressible) showed what the tape could do if supplied fast enough. Therein lay the problem, that the data wasn’t being sourced fast enough. Using large i/o buffers and a multithreaded utility like star made a huge difference.

With respect to cpu time, I don’t think the cost is associated with moving the bytes into or out of a buffer per se, but rather the entire code path or set of instructions that have to be executed. In some of the cases I’ve investigated, the cpu time cost was sufficient to represent a significant component of the elapsed time. As always though, its a good idea to measure it, so that its contribution is known. I suggest 100MB/s as a reasonable number where you might want to pay some attention to it.

То есть, с повышением требований к пропускной способности на уровне ввода-вывода и конкурентного использования издержки файлового кэша становятся заметнее. Использование прямого ввода-вывода и правильной буферизации программ/команд/функций, читающих или передающих данные, позволяет масштабировать систему.
Если речь идет о СУБД, то преимущества становятся заметны на больших объемах или под нагрузкой.

Ну ты же думаю понимаешь что перемещение больших файлов на пленку это далеко не то же самое что иголочные бд чтения записи с/на ссд к примеру, т.е. этот эксперимент абсолютно нерелевантен БД. То что кеш ФС неэфективен для длинных непрерывных записай общеизвестная тема.

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

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

У нас нигде mysql не используется. Ставить его себе только ради экспериментов я тоже не хочу.
Последняя ссылка на сегодня. Кто-то протестировал, по крайней мере. Не совсем сравнение с ФС, а скорее сравнение прямого ввода-вывода на разных файловых системах под линуксом.
dimitrik.free.fr/...e-linux-io.html

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

Рассказываю что там. Во-первых, тестовая конфигурация состоит из 1 (адын) файла данных.
Сначала сравниваются разные «планировщики ввода-вывода в линуксе», не знаю как правильно перевести I/O scheduler.
Дальше, точнее, до этого рассказывается о реализации «сырых» устройств на линуксе.
Дальше идет оценка производительности когда файл данных на raw device, и эти измерения и полученная пропускная способность берется за эталонную.
После чего последовательно тестируются EXT3, EXT4, XFS с разными опциями монтирования, включаяю опцию прямого доступа.
Оказывается, что в EXT3,4 прямой доступ реализован херово, так что даже с включением прямого доступа буферирование все равно имеет место быть.
XFS по производительности на графиках даже выглядит лучше (или сравнимо, во всяком случае) с прямым доступом чем с буферированным.
Теперь если посмотреть эту ссылку:
dimitrik.free.fr/...d-fusionio.html
Здесь тестируется производительность raw, EXT4, XFS на 1 файле, 2, 4, 8. Производительность буферизованного ввода-вывода выше только в одном случае: EXT4, 1 файл данных.
Во всех остальных случаях производительность прямого доступа выше, хотя и ясно что далека от производительности размещения файлов данных на «сырых» устройствах.

Рассказываю что там. Во-первых, тестовая конфигурация состоит из 1 (адын) файла данных.
Это где ты такое вычитал? Он там использует тулы, mysqlbench и iobanch про то сколько файлов они рожают ничего не известно.
XFS по производительности на графиках даже выглядит лучше (или сравнимо, во всяком случае) с прямым доступом чем с буферированным.
А где ты такое увидел? Помоему одинаково!
Теперь если посмотреть эту ссылку:
dimitrik.free.fr/...d-fusionio.html
Здесь тестируется производительность raw, EXT4, XFS на 1 файле, 2, 4, 8. Производительность буферизованного ввода-вывода выше только в одном случае
А где ты в этой статье увидел производительность буферизированного ИО? Там сравнивается только raw & direct.
Это где ты такое вычитал? Он там использует тулы, mysqlbench и iobanch про то сколько файлов они рожают ничего не известно.
Ты прикалываешься что ли?
Из первой ссылки:
“Workloads: Random Reads, Random Writes on a single 128GB file — it’s the most critical file access for any database (having a hot table, or a hot tablespace)”
1 файл данных, причем эти тулы вообще?
А где ты в этой статье увидел производительность буферизированного ИО? Там сравнивается только raw & direct.
Опять прикалываешься?
“While for Random-Read access it doesn’t make sense to test ‘fsync() case’ (the data will be fully or partially cached by the filesystem), but for Random-Write and Random-RW it’ll be pretty important. So, that’s why there are 4 cases represented on each graph containing Write test:
O_DIRECT with 4K block size
fsync() with 4K block size
O_DIRECT with 16K block size
fsync() with 16K block size”
1 файл данных, причем эти тулы вообще?
При том что он делал эту нагрузку тулами.
While for Random-Read access it doesn’t make sense to test ‘fsync() case’ (the data will be fully or partially cached by the filesystem)
Т.е. он решил не тестировать типичную БД нагрузку в котором буфер 100% выиграет?
o, that’s why there are 4 cases represented on each graph containing Write test:
O_DIRECT with 4K block size
fsync() with 4K block size
O_DIRECT with 16K block size
fsync() with 16K block size"
И как эти 4-е кейса представлены на графиках, не обьяснишь?

Первый, второй, третий, четвертый.
Красненькой пунктирной линией показано разграничение.
«the load is growing with 1, 4, 16, 64, 128, 256 concurrent IObench processes»
Это тот самый единственный тест где «write()+fsync() performs better than O_DIRECT»

Т.е. он решил не тестировать типичную БД нагрузку в котором буфер 100% выиграет?
Что это значит?
Там ясно написано «and of course all the I/O requests are completely random.. — yes, the worse scenario ;-)»

З.Ы. про 1 файл данных больше объяснять не надо, или ты и дальше будешь включать дурачка?

Это тот самый единственный тест где «write()+fsync() performs better than O_DIRECT»
Там все го два теста по сути, на ext4 всегда рулит буферизация, на xfs рулит directio.
Что это значит?
Там ясно написано «and of course all the I/O requests are completely random.. — yes, the worse scenario ;-)»
А это что значит? Я привел цитату, где он сказал что не будет тестировать nodirectio fs, потому что все равно ясно что она зарулит директ ио, потому что будет кешировать данные в памяти. Ну и вообще понятно что полностью рандомные риды — это уже не типичная бд нагрузка.

Ты путаешься в показаниях.
Сначала

Ну ты же думаю понимаешь что перемещение больших файлов на пленку это далеко не то же самое что иголочные бд чтения записи с/на ссд к примеру, т.е. этот эксперимент абсолютно нерелевантен БД. То что кеш ФС неэфективен для длинных непрерывных записай общеизвестная тема.
Теперь
Ну и вообще понятно что полностью рандомные риды — это уже не типичная бд нагрузка.
Ты уж определись, пожалуйста. Заодно может поделишься, что такое типичная бд нагрузка?
Там все го два теста по сути, на ext4 всегда рулит буферизация, на xfs рулит directio.
Там их не два.
Буферизация на EXT4 рулит в случае если есть 1(один) файл данных.
Дочитай хотя бы до середины что ли.
Начиная со слов «TEST with 8 data files».
Там сразу же идет тест EXT4, чтобы не распылять твое внимание.
Там даже для невнимательных в самом начале «summary»:
«You’ll see that:
* having 8 files brings FS performance very close the the RAW device level
* XFS is still performing better than EXT4
* having O_DIRECT gives a better results than write()+fsync()»
Ты путаешься в показаниях.
А в чем путаница? Ясен пень что база данных в которой все операции распределены абсолютно равномерно это сферический конь в вакууме. Обычно есть какие то горячие участки, и здесь всякие LRU кеши очень помогают, т.е. как раз то что делает буфер ФС.
Буферизация на EXT4 рулит в случае если есть 1(один) файл данных.
Ок, теперь какие твои выводы в контексте баз данных а не рандомных записей чтений в файл даже если их 8-емь?

Я свои выводы уже говорил.
Ты просил

эксперимент с стандартным mysql-евским бенчмарк тулом показал бы намного больше.
Я тебе показал ссылки с такими экспериментами.
Там выводы тоже написаны.
«you’re using O_DIRECT within your InnoDB config (don’t know yet if using 4K page size will really bring some improvement over 16K as there will be x4 times more pages to manage within the same memory space, which may require x4 times more lock events and other overheads.. — while in term of Writes/sec potential performance the difference is not so big! — from the presented test results in most cases it’s only 80K vs 60K writes/sec — but of course a real result from a real database workload will be better ;-))»

Еще раз говорю, что самый большой выигрыш получается от использования сырых разделов либо проприетарных файловых систем на неразмеченных разделах, обходя весь ненужный код таким образом и настраивая буфера обмена на уровне кода СУБД или промежуточного кода для работы с такими системами.
Но даже просто отключение буферизации (без асинхронного ввода-вывода) дает иногда заметный выигрыш, но самое главное, что это позволяет экономить ресурсы, так как память не засирается и процессор меньше используется.
Я говорю — иногда заметный. В моей практике это давало выигрыш всегда, просто не всегда его можно ощутить, если особых проблем не ощущается.
На этом я эту тему заканчиваю «засирать» тоже.
Если ты считаешь иначе, считай на здоровье.

Я тебе показал ссылки с такими экспериментами.
Я если честно не понял из твоих ссылок какие именно результаты получены с помощью бенчмаркинга MySql.
Не подскажешь?
Еще раз говорю, что самый большой выигрыш получается от использования сырых разделов либо проприетарных файловых систем на неразмеченных разделах, обходя весь ненужный код таким образом и настраивая буфера обмена на уровне кода СУБД или промежуточного кода для работы с такими системами.
Ну ведь нету end to end теста который подтверждает эту теорию? Или я что-то пропустил?
Но даже просто отключение буферизации (без асинхронного ввода-вывода) дает иногда заметный выигрыш, но самое главное, что это позволяет экономить ресурсы, так как память не засирается и процессор меньше используется.
А что значит «не засирается память»? И с чего ты взял что процессор меньше используется?

Теперь делаем то же самое, только с прямым доступом и на чтение, и на запись.
alexb@XXX:~$ dd if=test.tmp of=./test_cp.tmp bs=4M count=300 conv=notrunc oflag=direct iflag=direct
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 58.6896 s, 21.4 MB/s
alexb@XXX:~$ rm test_cp.tmp
alexb@XXX:~$ dd if=test.tmp of=./test_cp.tmp bs=4M count=300 conv=notrunc
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 58.9389 s, 21.3 MB/s

В данном случае выигрыша практически никакого.
О чем это говорит? О том что prefetch в ядре работает почти так же эффективно как и прямой доступ на таких операциях, но если мы имеем дело с СУБД, то это не только лишнее звено в цепи, но и отбор процессорных ресурсов.

alexb@XXX:~$ sudo time dd if=test.tmp of=./test_cp.tmp bs=4M count=300 conv=notrunc 
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 61.4573 s, 20.5 MB/s
0.00user 6.38system 1:01.47elapsed 10%CPU (0avgtext+0avgdata 19840maxresident)k
2457624inputs+2457600outputs (1major+1293minor)pagefaults 0swaps
alexb@XXX:~$ rm test_cp.tmp
rm: remove write-protected regular file `test_cp.tmp’? y
alexb@XXX:~$ sudo time dd if=test.tmp of=./test_cp.tmp bs=4M count=300 conv=notrunc oflag=direct iflag=direct
300+0 records in
300+0 records out
1258291200 bytes (1.3 GB) copied, 60.2474 s, 20.9 MB/s
0.00user 0.82system 1:00.27elapsed 1%CPU (0avgtext+0avgdata 19856maxresident)k
2457632inputs+2457600outputs (1major+1294minor)pagefaults 0swaps
--------------------------------------------------------
10%CPU против 1%CPU с включением прямого доступа. Теперь представим что буферный кэш, к примеру, 512G, совершенно средний по сегодняшним меркам. Предположим, 100-200 серверных процессов грузят данные в буферный кэш. Каждый из них «серит» понемногу (или помногу, в зависимости от настроек на уровне ФС и ОС) в файловый кэш и грузит на 10-15% доступный процессор/ядро/поток. То, что один процесс «серит» в файловый кэш, никак недоступно другим процессам, то есть, это абсолютный waste. В то же время, данные в буферном кэше немедленно разделяются всеми процессами.
Если теперь представить, что это таки большая база данных, и буферного кэша не хватает, т.е. активно используются прямые чтения, т.е. чтения в адресное пространство серверного процесса, а не в буферный кэш, чтобы не «засирать» уже его, то здесь файловый кэш — это просто катастрофа.
О том что prefetch в ядре работает почти так же эффективно как и прямой доступ на таких операциях, но если мы имеем дело с СУБД, то это не только лишнее звено в цепи, но и отбор процессорных ресурсов.
Что всего лишь теория не подтвержденная практикой. Еще раз, есть например база монгодб, она достаточно быстрая, в ней нету никаких кешей вообще, они полагаются на кеш ФС, что говорит о том что он не такой уж и тормоз. Что они делают не так?

Монгодб в моем представлении не РСУБД. Вот когда они начнут удовлетворять требованиям dirability, ну в общем.. даже тогда в моем представлении это не будет РСУБД.
Если работает успешно с файловым кэшем — это прекрасно, что еще можно сказать.

Монгодб не РСУБД by design вообщето, какой именно dirability тебя не устраивает в монге?

Durability. Опечатка вышла.
blog.mongodb.org/...bout-durability
Мне лично все равно, я монгу не использую и не собираюсь.
На эту тему дискуссию продолжать не вижу смысла, так как зачем читать что-то про то, что не используешь, не знаешь и не собираешься использовать.

Ок, т.е. ты написал про проблемы с Durability в монго не изучив вопрос. Бывает.

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

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

Из документации:
With journaling enabled, if mongod stops unexpectedly, the program can recover everything written to the journal, and the data remains in a consistent state. By default, the greatest extent of lost writes, i.e., those not made to the journal, are those made in the last 100 milliseconds. See journalCommitInterval for more information on the default.
Из другого места:
the write-ahead-log is fsync’ed every 100ms.
Вот и весь “дурабилити” — 100мс.

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

То есть, ты согласен что по умолчанию никакого «дурабилити» нет?
Теперь не очень понятно, можно ли (в отсутствие транзакций) получать подтверждение после каждой операции изменения, я в документации такого не нашел нигде. По поводу параметра journalCommitInterval.
Они сами путаются в показаниях. В одном месте
Specify an integer between 1 and 500 signifying the number of milliseconds (ms) between journal commits.
В другом
This option accepts values between 2 and 300 milliseconds.
В любом случае это не обеспечение долговечности, так как предполагается что «допустимые» потери ограничены этим параметром.
Ну и если ты объяснишь, каким образом синхронная репликация гарантирует «дурабилити», или при каких условиях, тогда конечно станет ясно вот это твое утверждение

Т.е. нет, данные не теряются, если нету никаких багов и проблем в других местах.
То есть, ты согласен что по умолчанию никакого «дурабилити» нет?
А я где то утверждал что она есть по умолчанию? Хотя она конечно есть на уровне репликации ))
Теперь не очень понятно, можно ли (в отсутствие транзакций) получать подтверждение после каждой операции изменения, я в документации такого не нашел нигде.
docs.mongodb.org/...d/getLastError
В любом случае это не обеспечение долговечности, так как предполагается что «допустимые» потери ограничены этим параметром.
Не понял почему.
Ну и если ты объяснишь, каким образом синхронная репликация гарантирует «дурабилити», или при каких условиях, тогда конечно станет ясно вот это твое утверждение
А что непонятно? Шанс вылета винта намного выше чем одновременного вылета 3-ех-4-ех машин в реплика сете, т.е. при репликации надежность выше.
Ок, т.е. ты написал про проблемы с Durability в монго не изучив вопрос. Бывает.
Не понял почему.
А что тут непонятного?
«In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently. » © любимая всеми википедия.
Если нет транзакций, предполагается, что любое изменение данных, затрагивающее состояние этих самых данных, является транзакцией.
Восстановиться могут только транзакции, попавшие в долговременное хранилище. Даже если выставить
journalCommitInterval
в 1, в зависимости от количества транзакций (операций) в секунду всегда есть шанс что какая-то часть попадет в этот промежуток. Им гарантированный кердык.
Теперь таки вопрос. Как репликация защищает от этого?

Да, забыл написать.
getLastError — это на уровне приложения. Как это гарантируется на уровне СУБД, если монго — это таки СУБД, как ты декларируешь?

А что тут непонятного?
«In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently. » © любимая всеми википедия.
Это очевидно кривое определение, durability очевидно может быть и без транзакций.
Восстановиться могут только транзакции, попавшие в долговременное хранилище. Даже если выставить
journalCommitInterval
в 1, в зависимости от количества транзакций (операций) в секунду всегда есть шанс что какая-то часть попадет в этот промежуток.
Ну вот getLastError и блокирует вызов пока не убедится что данные закомитились в лог и на заданное количество реплик.
Да, забыл написать.
getLastError — это на уровне приложения. Как это гарантируется на уровне СУБД, если монго — это таки СУБД, как ты декларируешь?
А так во всех БД сделано, если ты не напишешь специального кода на клиенте который проверяет что транзакция закомитилась, ты никогда не узнаешь закомитилась она или нет.

Понятно.

А так во всех БД сделано, если ты не напишешь специального кода на клиенте который проверяет что транзакция закомитилась, ты никогда не узнаешь закомитилась она или нет.
Никогда не работал с СУБД? Коммит означает что транзакция попала в долговременное хранилище. Никакого специального кода не нужно.
Это ты так троллишь?
Коммит означает что транзакция попала в долговременное хранилище. Никакого специального кода не нужно.
Это ты так троллишь?
НУ вот в jdbc ты вызываешь commit() в mongodb вызываешь getLastError, в обоих случаях удачное выполнение вызова означает что запись попала в долговременное хранилище. Что не так?

Разница в производительности. Но в общем, твоя мысль что getLastError и есть тем самым волшебным камнем, который обеспечивает durability.
Ну пусть будет так.

И какая же разница в производительности?

Pavel Kruchina тебе ответил, он прав. Спасибо Павел. query_cache, например, вообще лишний, если апдейты частые. А если редкие, то здорово помагает. Ты еще расскажи, что не нужен на рейд котроллерах кеш свой, если есть кеш файловой системы ...

ПС. опять пафос гдето ты увидел? о_О

Pavel Kruchina тебе ответил, он прав. Спасибо Павел. query_cache, например, вообще лишний, если апдейты частые. А если редкие, то здорово помагает.
А что именно он ответил касательно вопроса и в чем именно он прав?
ПС. опять пафос гдето ты увидел? о_О
Ну как же, преподавательский тон в том в чем дуба не рубишь.

это ты так воспринимаешь

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

Ebay не конкурент, а вот Etsy делает то же самое, но кто про него слышал в Украине-то?

но кто про него слышал в Украине-то?

Те кто смотрят и читают www.tested.com :P

У хендмейд сообщества своя «теплая ламповая» специфика. Полистайте ЖЖ, если интересно. Большинство людей занимается этим больше для души, чем для профита — смысл заморачиваться с e-bay? :)

Очень верно подмечено, Елена, а главное — такая логика доказана практически тем же etsy, которого присутствие e-bay ничуть не стесняет.

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

Таже фигня и с сайтами.

А success story о том, как выстрелил стартап, будет?

Кстати, да. Это было бы во-первых интереснее, во-вторых больше по теме для форума, в третьих — гораздо больше привлекает потенциального соискателя, в отличии от стереотипного «нам в команду нужен прогер»

Конечно! У нас очень скоро выходит релиз корпоративного блога, сама success story для него уже написана и трепетно хранится в док-те с названием «Битва против посредственности: 1:0 в нашу пользу»

Не завидую инвесторам...

Отчего такое трепетное отношение к чужим деньгам?

правильно, зависть — неконструктивное чувство, лучше порадуйтесь за них:)

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

Достаточно небольшого допила того же aukro — и целевая аудитория будет туда слита без копейки затрат. В отличие от ebay, он «мягче»: ориентирован на удовольствие выбора, а не на моментальную покупку.

В отличие от prom.ua, mash.ua не имеет множества посадочных площадок, то есть не является аэродромом. Возможно развитие в эту сторону, но пока его нет. К тому же, для хэндмэйда подход сомнителен.

Лично я увидел до боли знакомую модель «купи слона». Не купил.

Спасибо, что потратили время на такое развернутое пояснение, но:

1. Мы НЕ пошли в количественную раскрутку прототипом. Если под термином «количественная раскрутка» Вы имеете в виду слив денег на маркетинг, то нет, текущих показателей мы достигли без них:)
Мы придерживаемся принципа итерационного развития, в чем мы ошибаемся?)

2.

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

3. Специфика ниши заключается в том, что продажа — это акт коммуникации, а не просто транзакция. Хендмейд продавали и будут продавать и на aukro, и на e-bay, и на форумах, и в соц сетях. Другое дело, что для сервисов вроде etsy это не имеет значения, и именно такая специфика будет диктовать наш подход.

Алексей, на Mash есть много экзотических предложений, но вот слонов нет, увы:)

Странно, я увидел обратное. Тогда позвольте спросить, сколько лет ресурсу?
// если не жалко — покажите нам на доу презентацию, которую давали инвесторам.

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

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

Не лет — Mash полноценно работает около 10 месяцев, из которых 2 — период закрытой регистрации.

Я уверена, Вы не станете серьёзно утверждать, что перед релизом на рынке нам стоило «докрутить» Mash до уровня etsy:)

Я пока не вижу соотвествия между

30.000 уникальных товаров, 3.500 студий и мастеров
точечные активности в соц сетях
денег на маркетинг, нет, текущих показателей мы достигли без них
10 месяцев, из которых 2 — период закрытой регистрации.

Для меня это выглядит анекдотом про яблочный бизнес и наследство три миллиона. Однажды, когда взошла Луна, 3 500 студий и мастеров принесли 30 000 уникальных товаров к Лысой горе.

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

Алексей, наши показатели — факт. Наши методы — факт. Думаю, после «не верю» мы завершим нашу беседу и будем дальше делать вещи, в которые Вам сложно или даже невозможно поверить:)

Попробую сказать по-другому: сайт не имеет механизмов не только чтобы собрать воедино, но даже чтобы поддерживать жизнеспособной желаемую часть рынка. Эти показатели достигнуты другими методами (которые Вы не озвучиваете), другими информационными системами (о которых предпочитаете умалчивать), и конечно же — усилиями людей, о которых Вы говорите «немного».

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

Я как раз умею «делать вещи», почему и спрашиваю: Как это сделано? Я могу поверить, что не хотите говорить. Но поверить, что всё случилось само собой — не могу :)

Я рассчитывал увидеть это преимущество прямо на сайте. Захожу в роли мастера, или в роли клиента — и вот оно, на блюдечке. Но нет же. Я поглубже копнул — ноль. Почему и считаю сайт лишь прототипом: это движок и ничего кроме. Мне же хотелось увидеть ту изюминку, которой в нём нет. И если есть такое количество вовлечённых — значит изюминка есть. По-любому есть. Но в другом месте. Вот только где? Откуда произошёл этот сайт?

Алексей, вы думаете, вам кто-то все выложит на блюдечке, к тому же на форуме..... Я пока что никого не встречал, кто б все выкладывал, при личной встрече и вовлеченности, вам конечно раскроют карты....

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

В математики есть такой метод — комбинаторика. И для анализа проектов он годится лучше любого другого. Вместо копаться в деталях надежд и страхов основателей, просто предполагаю что проект работает, проблем нет. И смотрю, как он будет работать для +1 в каждой роли.

Если «+1» не работает, как в данном случае — есть 2 варианта:
1) Функция «+1» находится в другом проекте. Но этот как минимум странно, что зайдя на сайт я не могу к нему добраться.
2) Раньше работало, а теперь что-то поменяли и проект умирает.

// В случае вовлечённости проблема была бы поводом для серьёзного конфликта. Не дал бы загубить проект, и никаких отговорок.

Все, что я могу ответить — ну, ок:)

Собственно, проблема решается в 2 клика: сделай большие сслыки с mash.ua на группу ВКонтакте. Чтобы она была видна ещё до регистрации. Пересеки целевые аудитории, пусть клиенты mash подписываются на группу. Подписка — гарантия что придут снова.

Отдельное слово о презентации. Добавь раздел «кто мы», и пусть там будут ссылки на самое интересное. Блог, презентация, группа. В самой презентации следует добавить текстовое описание, до 200 символов (его же разместить в разделе). То есть рекламный вброс, заставляющий посмотреть презентацию.

Также рекомендую заказать себе рисованую аваторку. Сделанную лично для тебя, и чтобы ни у кого такой не было. Желательно в минимальном [не детализированном] стиле, рисунок который легко запоминается — из строгих линий или анимешный стиль. Возможно какой-то жест или присутствие предмета [можно то и другое]. Поищи подобные картинки, убедись насколько они приятны для глаза и делают любой ресурс персонализированным [в отличие от фотографий].

В дополнение нужно заиметь ники, желательно всей команде если они будут выходить в общение.

И моя личная просьба — найди для Mash нормальный шрифт, не такой вырвиглазный.

И если есть такое количество вовлечённых — значит изюминка есть. По-любому есть.
Знаете, мне эта дискуссия напоминает немного банальную шутку про «доказать, что ты не верблюд», в нашем случае «доказать, что ты несешь ценность».
Если Вам действительно интересно разобраться пошагово с нашими импульсными активностями, проектами «Строим Mash» и «Лаборатория» — пожалуйста, поделимся опытом в личном порядке, раз Вы уже уделили нам столько времени:)

Ну наконец-то ключевые слова. Спасибо, уже разобрался.
Жаль, конечно, что php не мой язык.
Проект интересный, кто хочет войти — рекомендую. Посмотреть кто есть кто можно здесь, здесь и вот здесь в первую очередь

// Неужели так сложно было в топике указать, всё выпытывать надо?

Ещё момент: проект работает на женской логике. Идеальный кандидат на работу — студентка 5 курса, желательно общительная. Обязательное хобби — хэндмэйд, общий интерес поможет делу. Желательно не мастер, а просто любитель, покупатель. Хобби можно преобрести по ходу дела, вместе с товаром.
Отдельный акцент: доходом является процент. То есть личное участие, общение в группе, и вообще желание использовать данный проект для себя — будут ключевыми мотивами.
Положительный фактор — если есть какие-то недостатки внешности (или просто неуверенность в ней). Именно товар ручной работы создаёт максимальную выгоду для таких людей, а также заставляет быть максимально требовательными клиентами. В частности, это может быть возраст «за 29». Отдельно добавлю, что именно это целевая клиентская аудитория, самые монетезируемые клиенты. Которым товар не просто побрякушки, а помогает улучшить качество жизни, дать доступ в желаемые социальные круги.
Вторая целевая аудитория — мамочки с дочками. Детям более чем кому либо необходимо быть уникальными, и разбираться в товаре. Однако, этот вариант подразумевает удалённую работу.

Как видишь, знание PHP вторично. Лучшим вариантом будет html/css, с желанием применять php не вдаваясь в глубокие дебри. Большинство работы будет связано с дизайном и человеческим фактором. SEO знать необязательно, в проекте уже есть специалист.

// Скажи ещё что ошибся :)

Простите, ещё пропустила аргумент:

В отличие от prom.ua, mash.ua не имеет множества посадочных площадок, то есть не является аэродромом. Возможно развитие в эту сторону, но пока его нет. К тому же, для хэндмэйда подход сомнителен.

Верно ли я поняла: у нас нет чего-то, что для нас сомнительно в качестве подхода?

Сомнительно в качестве главного (или единственного) подхода. Множество посадочных зон — хорошо [хоть и затратно, но решаемо]. Для для Вашего ресурса невыгодно быть множеством, выгоднее единство. Технически — это переходы с конкретных страниц на несколько целевых — каталоги, форумы, распродажи.

Простите, не увидела объяснения позиции, увидела повторение аргумента другими словами:)

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

И отдельно — спасибо за внимание к дискуссии, прочла у Вас «Никогда не общаюсь „от делать нечего“. Если я с Вами общаюсь — значит Вы мне чем-то полезны», восприняла буквально:)

Вакансии лучше размещать на
jobs.dou.ua
начните с jobs.dou.ua/register

А если я хочу разместить вакансию от имени частного лица (себя, то есть)? =)

Можно зарегистрировать компанию с названием проекта (если компании нет).

Подписаться на комментарии