Open osevan opened 3 years ago
Hi @osevan,
Thank for you reporting an issue and helping improve Kaltura!
To get the fastest response time, and help the maintainers review and test your reported issues or suggestions, please ensure that your issue includes the following (please comment with more info if you have not included all this info in your original issue):
# rpm -qa \"kaltura*\"
For deb based systems:
# dpkg -l \"kaltura-*\"
# tail -f /opt/kaltura/log/*.log /opt/kaltura/log/batch/*.log | grep -A 1 -B 1 --color \"ERR:\|PHP\|trace\|CRIT\|\[error\]\"
and paste the output.
For general troubleshooting see: https://github.com/kaltura/platform-install-packages/blob/Jupiter-10.13.0/doc/kaltura-packages-faq.md#troubleshooting-help
If you only have a general question rather than a bug report, please close this issue and post at: http://forum.kaltura.org
Thank you in advance,
The install
target has a dependency on the build
target, so you don't have to run make separately before make install - make install will build if needed. Usually these are run separately because make install needs sudo while make does not, but it's not mandatory.
The
install
target has a dependency on thebuild
target, so you don't have to run make separately before make install - make install will build if needed. Usually these are run separately because make install needs sudo while make does not, but it's not mandatory.
Thank you very much.
Why this?
add daemon off and master_process off to nginx.conf
Any benefits for profiling?
If you don't add these directives, nginx will run with multiple processes (master + workers) and these processes will most likely also run as different users (workers by default run as nobody
). IIRC, the profiling doesn't work in this case, for example, the master would run first, generate some of the files with user A, then the worker will start as user B and fail to update the files.
This is only for the profiling step, the final/production build should not use these directives.
If you don't add these directives, nginx will run with multiple processes (master + workers) and these processes will most likely also run as different users (workers by default run as
nobody
). IIRC, the profiling doesn't work in this case, for example, the master would run first, generate some of the files with user A, then the worker will start as user B and fail to update the files. This is only for the profiling step, the final/production build should not use these directives.
Thank you very much.
I want share with you nginx speedup with glibc alternative like Newlib and IP stack alternative lwip and malloc alternative mimalloc.
When you find a way compiling nginx with lwip and Newlib outside of micro kernel, you could inform me. 4 x times faster than default nginx librarys https://github.com/unikraft/lib-nginx
I wouldn't expect a significant boost with an alternative malloc, since nginx's pool implementation already groups the memory allocations into chunks. Nginx doesn't call malloc on every small string it needs to allocate - it allocates whole pages that are released only when the HTTP request is closed.
I wouldn't expect a significant boost with an alternative malloc, since nginx's pool implementation already groups the memory allocations into chunks. Nginx doesn't call malloc on every small string it needs to allocate - it allocates whole pages that are released only when the HTTP request is closed.
Give a try in your lab and figure out how we can compile outside microkernel
delete all object files - find objs/ -type f -name '*.o' -delete make install
Are you forget here make before make install - remember you need to compile second time after compiling with fprofile-generate.
Hope you can update me