boost beast async_write значительно увеличивает объем памяти - PullRequest
0 голосов
/ 17 февраля 2019

В настоящее время я экспериментирую с библиотекой надстроечного зверя и теперь очень удивлен ее объемом памяти.Используя три разных типа ответов (строковый, файловый, динамический), я обнаружил, что размер программы увеличивается до 6 МБ.

Чтобы приблизиться к причине, я взял небольшой пример сервера из библиотеки и уменьшил его.это к следующим шагам:

class http_connection : public std::enable_shared_from_this<http_connection>
{
public:
    http_connection(tcp::socket socket) : socket_(std::move(socket)) { }
    void start() {
        read_request();
    }

private:
    tcp::socket socket_;
    beast::flat_buffer buffer_{8192};
    http::request<http::dynamic_body> request_;

    void read_request() {
        auto self = shared_from_this();
        http::async_read(
            socket_, buffer_, request_,
            [self](beast::error_code ec,
                std::size_t bytes_transferred)
            {
                    self->write_response(std::make_shared<http::response<http::dynamic_body>>());
                    self->write_response(std::make_shared<http::response<http::file_body>>());
                    self->write_response(std::make_shared<http::response<http::string_body>>(), true);
            });
    }

    template <class T>
    void write_response(std::shared_ptr<T> response, bool dostop=false) {

        auto self = shared_from_this();

        http::async_write(
            socket_,
            *response,
            [self,response,dostop](beast::error_code ec, std::size_t)
            {
                if (dostop)
                    self->socket_.shutdown(tcp::socket::shutdown_send, ec);
            });
    }
};

когда я закомментирую три строки self-> write_response и скомпилирую программу и выполню команду size для результата, я получу:

   text    data     bss     dec     hex filename
 343474    1680    7408  352562   56132 small

Когда я удаляю комментарий первой записи, я получаю:

 864740    1714    7408  873862   d5586 small
   text    data     bss     dec     hex filename

После удаления всех комментариев конечный размер становится:

   text    data     bss     dec     hex filename
1333510    1730    7408 1342648  147cb8 small

4,8M Feb 16 22:13 small*

Теперь вопрос:

Я что-то не так делаю?

Есть ли способ уменьшить размер?

ОБНОВЛЕНИЕ

реальный process_request выглядит так:

void process_request() {

    auto it = router.find(request.method(), request.target());
    if (it != router.end()) {
        auto response = it->getHandler()(doc_root_, request);

        if (boost::apply_visitor(dsa::type::handler(), response) == TypeCode::dynamic_r) {
            auto r = boost::get<std::shared_ptr<dynamic_response>>(response);
            send(r);
            return;
        }
        if (boost::apply_visitor(dsa::type::handler(), response) == TypeCode::file_r) {
            auto r = boost::get<std::shared_ptr<file_response>>(response);
            send(r);
            return;
        }

        if (boost::apply_visitor(dsa::type::handler(), response) == TypeCode::string_r) {
            auto r = boost::get<std::shared_ptr<string_response>>(response);
            send(r);
            return;
        }
    }

        send(boost::get<std::shared_ptr<string_response>>(send_bad_response(
            http::status::bad_request,
           "Invalid request-method '" + std::string(req.method_string()) + "'\r\n")));
}

Заранее спасибо

Ответы [ 2 ]

0 голосов
/ 18 июня 2019

Попробуйте использовать malloc_trim(0), например: в деструкторе http_connection.

из man: malloc_trim - освободить свободную память из верхней части кучи.

malloc_trim () функция пытается освободить свободную память в верхней части кучи (вызывая sbrk (2) с подходящим аргументом).

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

Если этот аргумент равен 0, в верхней части кучи поддерживается только минимальный объем памяти (т. Е. Одна страница или меньше) .Ненулевой аргумент может использоваться для сохранения некоторого конечного пространства в верхней части кучи, чтобы можно было выполнять будущие выделения без необходимости расширения кучи с помощью sbrk (2).

0 голосов
/ 17 февраля 2019

Если у вас на самом деле нет утечки памяти, то в этом нет ничего плохого.Независимо от того, какая память выделена системой, она будет либо повторно использована для вашей программы, либо в конечном итоге возвращена.Из-за системы виртуальной памяти очень трудно измерить истинное использование памяти программой, особенно в Linux.Если вы не увидите фактическую утечку или реальную проблему, я проигнорирую эти отчеты о памяти и просто продолжу реализацию вашей бизнес-логики.Сам зверь не содержит утечек памяти (тщательно протестирован на коммитах на Travis и Appveyor под valgrind, asan и ubsan).

...