И всё же:
1. Может по подробнее расписать, чего не хватает в языке запросов в самом Postgres?
2. Если не хватало скорости то вы использовали GIN или GIST индекс?
3. Если нужно работать с тегами то ИМХО лучше воспользоватся intarray. В моём usecase мне помогло ну и в 9.6 я исправил планировщик (точнее оценку селективности, оно теперь пытается гистограммы использовать).
что в том числе отличает их от серверов и мэйнфреймов (англ. mainframe) — компьютеров с высокой общей производительностью, призванных решать типовые задачи (например, обслуживание больших баз данных или одновременная работа с множеством пользователей).
Поверьте superdome не для типовых задач. И не смотря на NUMA, просто запустить приложение в N потоков не даст особого плюса и реально всё раскрывается только на приложениях работающих с ним скорее как с MPP. Там очень большая латентность на синхронизацию между некоторыми нодами… (CAS/TAS очень больно)
У RHEL могут быть конечно глюки с их лицензией но на любом другом свободном дистре вы можете поставить ядро сами из исходников (даже не на gentoo), и там у вас все руки развязаны. Лично я тестировал системы Power8 c SMT8 где 512 «потоков-ядер».
Супер компьютеры все поголовно работают на Linux и там куда больше 5000 ядер бывает.
В общем ядер становится всё больше и проблемы их эффективного использования всё возрастают.
Это прикладные проблемы, а не ОС. Самый простой вывод — запускайте больше сервисов на одной машине.
Собственно ничего не писал, я же не знаю за что конкретно забанили. Сайт всё же достаточно чист и проходит требования AdSense.
т.е. опять, если вы просто перейдёте по ссылке никакой клубнички вы не увидите. И опять же как сайт связан с приложением? Приложение было чисто. :(
А так в первую очередь приложение pixiv и vk.com надо удалять срочно, там порно есть, доступно и почти не скрыто.
На pixiv точно не запрещена.
Теперь и моё приложение Anime Pictures и мой аккаунт пополнили эти ряды.
Сначала удалили приложение, потом когда подал апелляцию просто удалили аккаунт.
Я просто их не понимаю. :(
ЗЫ удалили за сексуальное содержание, которого небыло в приложении. Правда после регистрации можно получить на сайте но это отдельная история которая не имеет отношения к приложению.
Предупреждаю т.к. недавно наткнулся: в любимой под Linux файловой системе XFS это работать не будет, без спец настройки ФС. :(
В итоге кусок кода на stat переводил обратно (но там время обхода не кретично).
Меня всё удивляет Michael Paquier который из Японии но француз… :) Но это правда из постгресовой тусовки. А вообще у IT специалистов в этом плане всегда всё интересно. :)
А теперь главный вопрос — зачем? дабы небыло гонок? Это как бы ооочень плохой вариант, так как вы по сути фризите весь поток выполнения. Вам тут барьеры нужны да мьютексы, а не вот этот кастыль.
Все вызовы в кнешним ресурсам должны быть неблокируемыми. Даже по unix-сокету (это не сильно то и быстрее tcp через лупбэк интерфейс).
Тут всё просто — сходить в memcached за данными быстрее чем отдать это дело в event loop. Питон существо не самое быстрое.
go на уровне рантайма так же использует event loop.
Ну так весь вопрос в том, работаете ли вы с event loop напрямую или же опосредованно в рамках много поточного программирования. Когда вы пишите код в nginx или поверх libevent вы работает с event loop явно из Си.
Ещё как контролирую. Я могу сделать запрос к memcache в блокирующем режиме (в целом как и советую если он по unix-sockets), а уже для тяжёлого SQL запроса сделать yield (и только тогда я верну управление event loop'у).
А никто и не делает,
Противоречит:
я не вижу ровным счетом никаких недостатков в модели выполнения go
И вообще не уверен, что всё это сравнивать корректно в Go это просто легковесные потоки (треды), а в Python это синтаксический сахар к event loop машине. Притом, что Threades в Python это скорее аналог горутин (за счёт GIL), хотя и гораздо более примитивный. К слову появились и пулы процессов/тредов для вот такого:
https://docs.python.org/3.5/library/concurrent.futures.html#concurrent.futures.Executor
ЗЫ полезность event loop машины можно только показать тем, что nginx по сути использует именно её. Т.е. это вполне рабочее решение со своими плюсами.
И я все еще не понимаю чем вариант go, который самый простой и эффективный в плане работы с I/O, неудобен.
Ну разница как между ASM и C++ т.е. в некоторых ситуациях я сам лучше знаю когда и что нужно прервать.
Но тут языки сравнивать мне кажется глупо т.к. Go компилируется хоть и с GC, а Python интерпретируется хоть и байткод.
Кроме того, вы точно знаете где можете наткнутся на проблему гонок т.к. переключение явное. Т.е. это бывает полезно + это ещё один интересный подход которого нету в Go.
Но это не значит, что подход Go плох, но всё же не стоит делать из него silver bullet.
Вывод — горутины это так же неявно как и await/yield но намного удобнее и производительнее.
Вот тут я несогласен. async/yield это кок раз явно т.е. вы явно задаёте когда уходите в event loop. Горутины же больше похоже на микро планировщик из ОС. В Go нельзя явно не уходить в «event loop».
Явная асинхронность это когда вы явно в коде задаёте когда уходим в event loop. Это может быть callback или более удобный async/yield.
Неявная это когда вы не имеете полный контроль над этим. Мне ближе явный подход.
А что если объеденить идею потоков и корутин? мы получим горутины. То есть в go это все те же (ну не совсем, я все же утрирую) корутины. которые собраны в пулы и раскиданы между потоками.
Это всё tradeof между удобством и потреблением оперативки. По сути если вы запускаете в несколько потоков Python то получаете аналогичную ситуацию с Go.
В Go асинхронность неявная (gorutine). Насколько я понимаю, языки с явной асинхронностью это Python, C#, NodeJS (и возможно будет Rust).
Я не говорю, что это плохо, просто есть разница между написанием по сути multi thread кода (Go) и асинхронного пусть даже с async/yield.
Я делал крайне сложные вещи для iOS6 и использованием flexbox и в целом всё хорошо. (без flexbox это не решалось бы вообще)
Так, что я за flexbox с префиксами, чем за inline-block у которого то же болячки есть.
1. Может по подробнее расписать, чего не хватает в языке запросов в самом Postgres?
2. Если не хватало скорости то вы использовали GIN или GIST индекс?
3. Если нужно работать с тегами то ИМХО лучше воспользоватся intarray. В моём usecase мне помогло ну и в 9.6 я исправил планировщик (точнее оценку селективности, оно теперь пытается гистограммы использовать).
Спасибо.
Поверьте superdome не для типовых задач. И не смотря на NUMA, просто запустить приложение в N потоков не даст особого плюса и реально всё раскрывается только на приложениях работающих с ним скорее как с MPP. Там очень большая латентность на синхронизацию между некоторыми нодами… (CAS/TAS очень больно)
Супер компьютеры все поголовно работают на Linux и там куда больше 5000 ядер бывает.
Это прикладные проблемы, а не ОС. Самый простой вывод — запускайте больше сервисов на одной машине.
Собственно ничего не писал, я же не знаю за что конкретно забанили. Сайт всё же достаточно чист и проходит требования AdSense.
т.е. опять, если вы просто перейдёте по ссылке никакой клубнички вы не увидите. И опять же как сайт связан с приложением? Приложение было чисто. :(
А так в первую очередь приложение pixiv и vk.com надо удалять срочно, там порно есть, доступно и почти не скрыто.
На pixiv точно не запрещена.
Сначала удалили приложение, потом когда подал апелляцию просто удалили аккаунт.
Я просто их не понимаю. :(
ЗЫ удалили за сексуальное содержание, которого небыло в приложении. Правда после регистрации можно получить на сайте но это отдельная история которая не имеет отношения к приложению.
А в чём проблема использовать firstletter?
http://linux-tips.org/t/readdir-function-on-xfs-filesystem-not-working-properly/115
В итоге кусок кода на stat переводил обратно (но там время обхода не кретично).
Тут всё просто — сходить в memcached за данными быстрее чем отдать это дело в event loop. Питон существо не самое быстрое.
Ну так весь вопрос в том, работаете ли вы с event loop напрямую или же опосредованно в рамках много поточного программирования. Когда вы пишите код в nginx или поверх libevent вы работает с event loop явно из Си.
Ещё как контролирую. Я могу сделать запрос к memcache в блокирующем режиме (в целом как и советую если он по unix-sockets), а уже для тяжёлого SQL запроса сделать yield (и только тогда я верну управление event loop'у).
Противоречит:
И вообще не уверен, что всё это сравнивать корректно в Go это просто легковесные потоки (треды), а в Python это синтаксический сахар к event loop машине. Притом, что Threades в Python это скорее аналог горутин (за счёт GIL), хотя и гораздо более примитивный. К слову появились и пулы процессов/тредов для вот такого:
https://docs.python.org/3.5/library/concurrent.futures.html#concurrent.futures.Executor
ЗЫ полезность event loop машины можно только показать тем, что nginx по сути использует именно её. Т.е. это вполне рабочее решение со своими плюсами.
Ну разница как между ASM и C++ т.е. в некоторых ситуациях я сам лучше знаю когда и что нужно прервать.
Но тут языки сравнивать мне кажется глупо т.к. Go компилируется хоть и с GC, а Python интерпретируется хоть и байткод.
Кроме того, вы точно знаете где можете наткнутся на проблему гонок т.к. переключение явное. Т.е. это бывает полезно + это ещё один интересный подход которого нету в Go.
Но это не значит, что подход Go плох, но всё же не стоит делать из него silver bullet.
Вот тут я несогласен. async/yield это кок раз явно т.е. вы явно задаёте когда уходите в event loop. Горутины же больше похоже на микро планировщик из ОС. В Go нельзя явно не уходить в «event loop».
Явная асинхронность это когда вы явно в коде задаёте когда уходим в event loop. Это может быть callback или более удобный async/yield.
Неявная это когда вы не имеете полный контроль над этим. Мне ближе явный подход.
Это всё tradeof между удобством и потреблением оперативки. По сути если вы запускаете в несколько потоков Python то получаете аналогичную ситуацию с Go.
Я не говорю, что это плохо, просто есть разница между написанием по сути multi thread кода (Go) и асинхронного пусть даже с async/yield.
Так, что я за flexbox с префиксами, чем за inline-block у которого то же болячки есть.