Comments (5)
Concerning Lwt_io, the "fix" is only in the new cohttp-server-lwt-unix
, where we remove the dependency on conduit
and move to Lwt_io.direct_access
, see mirage/ocaml-cohttp#898 and mirage/ocaml-cohttp#907 (the package was introduced in mirage/ocaml-cohttp#838).
This goes hand in hand with the new very fast parser introduced in mirage/ocaml-cohttp#819 and later improved and moved to the general http package. The PR that introduces it also includes some
@rgrinberg @anuragsoni @kandu please correct me or integrate with anything I may be missing or misremember.
from lwt.
@rgrinberg In the cohttp issue discussion you mention
The issue was successfully worked around in the new cohttp client and servers though.
Do you have pointers to the fix? Maybe a PR number?
from lwt.
I haven't really worked on the Lwt_bytes
/Lwt_io
part of Lwt. I'll try to have a look some time, but that will be a big context switch so I can't do it right now.
As a low-hanging fruit (hopefully) I'll try to understand the patterns that can be problematic and update the documentation accordingly. An actual fix may come later.
from lwt.
@mseri I agree with the assessment that the new cohttp-server-lwt-unix
is where this issue is probably "resolved" for cohttp. It should still be tested with the example in the original issue though to confirm this. For the cohttp-lwt
packages there has been no change in its use Lwt_io
so unless things have changed within lwt, i'd think that the issue still persists for cohttp + lwt.
from lwt.
I have tried to experiment a little more to get a better understanding about memory consumption in the Ocsigen stack. But I'm getting more confused. I have a small test app that just sends notifications from server to client. When it sends notifications at a rate at about 50/s the application slowly increase memory consumption. If I increase the rate to 100/s, memory consumption increases. However, if I increase the rate to 200/s (or more), then memory consumption stays low,
at around 30MB.
Similarly, if I have other applications using most of the available memory before starting my application, then memory usage stays low. Also, I have seen that in some cases the application will give back memory to the OS if other applications starts using a lot of memory after the "Ocsigen" application has started consuming memory.
From my observations, it does not look like memory leakage, but but rather like a memory allocation/caching strategy that does not always works the way I would like. I guess this is more or less similar to what others have reported.
Is there no way for application writers to change/control the memory consumption behavior?
from lwt.
Related Issues (20)
- How to use Lwt_unix with OCaml 5 effects? HOT 3
- Exception printed in Lwt_stream.bounded_push#close documentation HOT 1
- Provide `Lwt.sleep` as a Unix-less function HOT 3
- Ppx_lwt docs link returns 404 error (since 5.4.0) HOT 1
- Drop support for OCaml < 4.08.0 HOT 4
- `src/unix/config/discover.exe` puts too much `-I` includes which can mislead the compiler
- EBADF from Lwt_process.with_* HOT 4
- Support `Lwt_process` in multi-domain settings HOT 1
- passing `env` in `Lwt_process` doesn't work on Windows HOT 1
- forking breaks lwt-io if happens after Lwt_main.run HOT 3
- Ocaml 5 build issue HOT 3
- Default Unix pool size (1000) is insane and dangerous
- SIGSEGV on OCaml 5 due to missing SA_ONSTACK HOT 2
- Clarify documentation of Lwt_stream.get_available
- Have a separate set of `Lwt_process.pread` that also return the process status HOT 2
- Documentation of `Lwt_stream.create` and `Lwt_stream.get`
- Need a way to share SIGCHLD with other libraries HOT 2
- Race in worker_loop HOT 1
- Library not found for `-llwt_unix_stubs` on macOS HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lwt.