Марлик вернулся

Ага, тишину нарушать буду теперь.

Гайс, а какие есть бест праксис для кеширования данных из бд, если это не орм?

То есть грубо говоря, считал я пару таблиц, и логично их закешировать по ключу и брать из кеша, пока ключ совпадает и кеш не устарел. Как это лучше реализовать?

Как с этой бедой бороться? Отключать? gometalinter --fast --no-vendored-linters --vendor ./... WARNING: deadline exceeded by linter vetshadow (try increasing --deadline) WARNING: deadline exceeded by linter vet (try increasing --deadline) WARNING: deadline exceeded by linter gosec (try increasing --deadline)

Гайс, а какие есть бест праксис для кеширования данных из бд, если это не орм?

так же, как и с орм :)

так же, как и с орм :)

Стало немножко лучше, но все еще нет)

Прост орм часто включают такой функционал, поэтому уточнил

Прост орм часто включают такой функционал, поэтому уточнил

посмотреть его реализацию в орм и сделать так же?)

Да хорош рофлить

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

Просто до этого работал с языком, у которого из коробки буферизация запросов есть

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

Наверняка кто поумней меня уже все придумал

Ну вроде самое простое - это когда ключ = сам запрос, а значение результаты? И в редисе хранить

Реализуется элементарно

Реализуется элементарно

А если много записей читаю? Норм их отдельно по ключу в редис класть? Или целой таблицей?

Много записей - это же конкретный запрос :) и на него есть конкретные результаты.

Много записей - это же конкретный запрос :) и на него есть конкретные результаты.

Да, согласен

Это разумно

Как-то и не задумывался в таком ключе

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

смотрите, у меня есть веб-приложуха, которую я реализовал по вот этой статье https://medium.com/smsjunk/handling-1-million-requests-per-minute-with-golang-f70ac505fcaa

в каждом воркере идут запросы на отдельные урлы с таймаутами по http, по сути, это кроулер

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

при этом дамп pprof пустой, то есть приложение висит не в юзерспейсе (ну либо что-то крайне быстро отрабатывает)

strace показывает, что futex'ы бесятся, то есть не зависание на сисколле, а какая-то битва где-то за что-то

как найти проблему?

Долго это сколько?

Приделай таймаутов, какой-нибудь оборвется, там и будет проблема

так в том-то и дело, что таймаут на http клиенте стоит

10 секунд

но запуск всей фигни на одних и тех же урлах может занять 10 секунд, а может 1500 секунд

вроде количество дескрипторов повысил - не помогло

Гайс, а какие есть бест праксис для кеширования данных из бд, если это не орм?

Использовать средства кэширования самой базы.

strace показывает, что futex'ы бесятся, то есть не зависание на сисколле, а какая-то битва где-то за что-то

Танцы футексов, обычно, это шедуллер, значит все повисло

Использовать средства кэширования самой базы.

Иначе убьешься кэш инвалидировать

Танцы футексов, обычно, это шедуллер, значит все повисло

вообще сейчас уже нет, я только что проверил - висит на фьютексе

и у процесса стейт Sl

Иначе убьешься кэш инвалидировать

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

что он там может такое ждать и почему таймаут не срабатывает?

Днс? Хендшейк?

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

Кэш в бд быстрый. По сути ключ-значение тоже самое.

Подсунь dialer с дебагом

Днс? Хендшейк?

я dns-запрос руками делаю с таймаутом перед http

и если он не отрабатывает - даже не пытаюсь http

Кэш в бд быстрый. По сути ключ-значение тоже самое.

Можно делать риды со слейва.

я dns-запрос руками делаю с таймаутом перед http

А по графу непонятно, какая ветка в футекс ушла? Pprof я имею ввиду

А по графу непонятно, какая ветка в футекс ушла? Pprof я имею ввиду

я вот сейчас прошел руками по всем тредам - судя по всему, висит вызов epoll_pwait()

но я понятия не имею, что это может значить и, опять же, почему таймаут не отрабатывает

не, я знаю, что такое epoll

Медленное чтение?

я не понимаю, почему на нем висит

Медленное чтение?

да вот фиг знает, таймаут-то на все сразу должен быть, разве нет?

Попробуй readtimeout прокрутить

Попробуй readtimeout прокрутить

такой настройки нет для клиента, как я понимаю https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/

http://qr.ae/TUGK8h

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

а транспорт настраиваете? максимальное количество коннектов одновременны к одному серверу, и все вот это вот?

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

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

что такое зависнуть?

зависнуть там ничего не может

может ждать отправки или получения данных

может ждать отправки или получения данных

я выше написал, один из тредов ожидает на epoll_pwait крайне долго, и таймаут для http-клиента не помогает

еполл - это вы очень глубоко отправились

транспорт вы настраиваете?

ERROR: S client not available

еполл - это вы очень глубоко отправились

выдача pprof пустая

конечно она пцустая - у вас же приложение не делает ничего

транспорт вы настраиваете?

я ему выставляю InsecureSkipVerify: true

больше ничего

это TLS

конечно она пцустая - у вас же приложение не делает ничего

да, это и напрягает, что таймаут не соблюдается

ну вот посмотрите, сколько всего полезного можно настроить: https://golang.org/pkg/net/http/?#Transport

Слушайте, а почему собственно не иметь возможность запускать разные goroutine'ы в разных runtime'ах с отдельным scheduler'ом?

это конечно повысит memory-footprint, но для time-critical applications это было бы вполне полезно

на одном рантайме 100.000 горутин занимаются всяким I/O, на другом рантайме 12 горутин занимаются обработкой time-critical заданий

это все зачем?

это все зачем?

да если даже про тот-же рендеринг говорить.. чтоб 100к горутин которые занимаются всяким I/O не крали время у тех горутин, которые занимаются time-critical заданиями как рендеринг на экран..

коллега, нет никакого рендеринга

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

откуда у горутин приоритеты

на одном рантайме 100.000 горутин занимаются всяким I/O, на другом рантайме 12 горутин занимаются обработкой time-critical заданий

А зачем писать критичное ко времени на языке 1) с GC 2) с плохо оптимизирующим компилятором?

ладно, пойду еще на 8 часов замьючу чатик

А зачем писать критичное ко времени на языке 1) с GC 2) с плохо оптимизирующим компилятором?

вы этого хотели, коллега Роман? тупого комментария про GC?

откуда у горутин приоритеты

Читал об этой идее в доке о дизайне планировщика в версии 1.1

в общем и целом идея сдохла (и хорошо)

горутины хорошо работают в ситуации, когда у нас есть запас по процессору.

коллега, нет никакого рендеринга

это чисто пример, я не говорю что нам надо обязательно рендерить на Go))) просто collective concurrency это хорошо для массовой параллельности аля API-server. но для time-critical concurrency это ужасно.. если у нас 4 горутины играют роль DSP (signal processing) и пораждают дополнительные горутины для обработки асинхронных тасков, то растущее колво дополнительных горутин будет отрицательно влиять на точность работы первых 4, они будут красть у тех время. Т.е. на данный момент Go совершенно не применим для time-critical + massively parallel, что можно бы было изменить приоритетностью определённых горутин поместив их в некие "work groups"

а когда запаса по процессору нет - хорошо не будет, с приоритетами или без

это чисто пример, я не говорю что нам надо обязательно рендерить на Go))) просто collective concurrency это хорошо для массовой параллельности аля API-server. но для time-critical concurrency это ужасно.. если у нас 4 горутины играют роль DSP (signal processing) и пораждают дополнительные горутины для обработки асинхронных тасков, то растущее колво дополнительных горутин будет отрицательно влиять на точность работы первых 4, они будут красть у тех время. Т.е. на данный момент Go совершенно не применим для time-critical + massively parallel, что можно бы было изменить приоритетностью определённых горутин поместив их в некие "work groups"

DSP? я тут поговорил с одним sound-инженером. latency в миллисекунду для них вполне приемлемо. в миллисекунду! для dsp нам ничего специально делать не надо...

короче

хотите меньше latency - добавьте ядер

а приоритеты для горутин - это смешно

А зачем писать критичное ко времени на языке 1) с GC 2) с плохо оптимизирующим компилятором?

я абсолютно согласен что лучше просто взять C++ / Rust и не париться! Но тем не менее размышляю над тем как оправдать титул "general purpose programming language", поскольку на Go гораздо легче писать чем на C++ / Rust С гошным GC в принципе можно жить поскольку он оптимизирован не на throughput а на latency, главное мусора не создавать и всё будет окей.

для SDL2 рендеринга делаю 15 милисекундный слип , итог 30 fps

а приоритеты для горутин - это смешно

скорее не приоритеты а work-group'ы)

еще смешнее