Столкнулся с такой проблемой, go изучал самостоятельно и, возможно, что-то упустил. Есть высоконагруженный сервис, раньше работал в качестве источника данных с Redis, но начались просадки на общении с базой. Была сделана доработка in memory DB внутри сервиса, 30 гигов в оперативке. Скорость стала приемлемой, но есть пики, которые возникают в момент работы GC. Можно ли как-то решить данную проблему, сомневаюсь, что у меня получится уменьшить количество данных в куче, ну если извернусь, то процентов на 5-10 не больше. Может можно как-то выделить пару ядер на GC) Или данная задача в принципе не решается на данном стеке.
Working mode Requests per sec 100 Working time sec 300 Requests sent 30000 Requests loss 0 loss in percent 0.00%
Histogram map[100:29895 200:100 300:5] Request Avg Answer Duration 3.703623ms Request Min Answer Duration 1.18272ms Request Max Answer Duration 207.433021ms
Столкнулся с такой проблемой, go изучал самостоятельно и, возможно, что-то упустил.
Есть высоконагруженный сервис, раньше работал в качестве источника данных с Redis, но начались просадки на общении с базой. Была сделана доработка in memory DB внутри сервиса, 30 гигов в оперативке. Скорость стала приемлемой, но есть пики, которые возникают в момент работы GC. Можно ли как-то решить данную проблему, сомневаюсь, что у меня получится уменьшить количество данных в куче, ну если извернусь, то процентов на 5-10 не больше. Может можно как-то выделить пару ядер на GC) Или данная задача в принципе не решается на данном стеке.
Working mode Requests per sec 100 Working time sec 300
Requests sent 30000 Requests loss 0 loss in percent 0.00%
Histogram map[100:29895 200:100 300:5]
Request Avg Answer Duration 3.703623ms
Request Min Answer Duration 1.18272ms
Request Max Answer Duration 207.433021ms