I use 'debug.FreeOsMemory'. But it is not the certain.
在 2019年6月24日星期一 UTC+8上午10:59:06，Chou Yan写道：
>
> My server have 100G memory.
> I limit my server 60G by cgroups.
> But my app process use the momory more and more !
> even more than 50G.
> my prof:
>
> # HeapIdle = 27377164288
> # HeapInuse =
I am use 'debug.FreeOsMemory'. But it is not the certain.
在 2019年6月24日星期一 UTC+8上午10:59:06，Chou Yan写道：
>
> My server have 100G memory.
> I limit my server 60G by cgroups.
> But my app process use the momory more and more !
> even more than 50G.
> my prof:
>
> # HeapIdle = 27377164288
> # HeapInuse
some of gc logs:
gc 8639 @331692.423s 6%: 60+2541+2.3 ms clock, 1928+112357/40484/0+75 ms
cpu, 22264->22299->4575 MB, 23164 MB goal, 64 P
gc 8640 @331719.932s 6%: 21+2580+1.5 ms clock, 673+106151/41127/0+48 ms
cpu, 21976->22064->4769 MB, 22878 MB goal, 64 P
gc 8641 @331759.750s 6%: 31+2671+1.6 ms
My server have 100G memory.
I limit my server 60G by cgroups.
But my app process use the momory more and more !
even more than 50G.
my prof:
# HeapIdle = 27377164288
# HeapInuse = 21910396928
The Cgroup will kill the process when it use more than 60G
But golang runtime gc will not release the
We are trying to make the x32 version of the extension, as shown in the
link below.
https://community.bistudio.com/wiki/Extensions#C.2FC.2B.2B
How we see, for x64 we must use entry points
- RVExtension
- RVExtensionArgs
- RVExtensionVersion
but for x32
- _RVExtension@12
- _RV
thanks you Marvin for this interesting article. You point the real problem
:)
Le dimanche 23 juin 2019 22:55:05 UTC+2, Marvin Renich a écrit :
>
> * nicolas_boiteux via golang-nuts >
> [190623 15:33]:
> > Precisly, i don't know what is this @12, and nobody can explain this :(
> > It's for a wi
remove the _ underscore.
> On Jun 23, 2019, at 2:20 PM, Kurtis Rader wrote:
>
>> On Sun, Jun 23, 2019 at 4:49 AM nicolas_boiteux via golang-nuts
>> wrote:
>
>> I need some assistance to export a GO dll function to a C program.
>>
>> The C program (wich i m not the author) required to call a
* nicolas_boiteux via golang-nuts [190623 15:33]:
> Precisly, i don't know what is this @12, and nobody can explain this :(
> It's for a windows build and the dll is load by arma game.
The leading '_' and trailing '@' followed by a number is the __stdcall
decoration for a C name in the produced
Hello Kurtis,
Precisly, i don't know what is this @12, and nobody can explain this :(
It's for a windows build and the dll is load by arma game.
more informations at this place:
https://community.bistudio.com/wiki/Extensions
in c#, i used this line for export 32 bits dll
[DllExport("_RVExtensi
On Sun, Jun 23, 2019 at 4:49 AM nicolas_boiteux via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I need some assistance to export a GO dll function to a C program.
>
> The C program (wich i m not the author) required to call a function with
> this name: _RVExtension@12
>
That is not a val
as asked by Jason, i give more information.
I build a 32 bits .dll and there was no error message. When i launch the
dll with the c program, the c program return a generic error message
"method is not recognized" wich happens when the entry point name is wrong.
So the C program expected a funct
Looks very nice, I look forward to checking it out.
I'm curious: why do you maintain separate trees for the single node vs.
cluster version? Naively I would have assumed that single node == cluster
codebase with a few features turned off at runtime, and there seems to be a
lot of overlap between t
the dll is build but the entry point not works correctly :(
Le dimanche 23 juin 2019 19:10:52 UTC+2, nobody nobodye a écrit :
>
> thanks you for your answer. I will check for this :)
>
> Le dimanche 23 juin 2019 18:58:22 UTC+2, Jason E. Aten a écrit :
>>
>> The @12 part isn't legal as part of a fu
On Sun, Jun 23, 2019 at 8:34 PM Jason E. Aten wrote:
> very nice.
>
> https://github.com/klauspost/compress just added zstd all in Go, might
> be a lovely way to remove the CGO dependency.
>
I'm keeping eye on it! Currently cgo version of zstd has slightly better
performance comparing to pure G
very nice.
https://github.com/klauspost/compress just added zstd all in Go, might be
a lovely way to remove the CGO dependency.
On Tuesday, June 18, 2019 at 8:15:20 AM UTC-5, Aliaksandr Valialkin wrote:
>
> Hello all,
>
> I'm happy to announce VictoriaMetrics - fast open source time series
> d
thanks you for your answer. I will check for this :)
Le dimanche 23 juin 2019 18:58:22 UTC+2, Jason E. Aten a écrit :
>
> The @12 part isn't legal as part of a function name, as the compiler is
> telling you. You must remove it.
>
> On Sunday, June 23, 2019 at 6:49:33 AM UTC-5, nicolas...@yahoo.f
The @12 part isn't legal as part of a function name, as the compiler is
telling you. You must remove it.
On Sunday, June 23, 2019 at 6:49:33 AM UTC-5, nicolas...@yahoo.fr wrote:
>
> Hello,
>
> I need some assistance to export a GO dll function to a C program.
>
> The C program (wich i m not the a
The spec is at phase 2. Please feel free to subscribe to
https://github.com/golang/go/issues/28631 for updates.
On Saturday, 22 June 2019 06:46:56 UTC+5:30, Keith Randall wrote:
>
> No, it doesn't. Do wasm threads exist yet? When the wasm port was first
> developed, they didn't exist.
> If the s
Hello,
I need some assistance to export a GO dll function to a C program.
The C program (wich i m not the author) required to call a function with
this name: _RVExtension@12
so, i simply declare my go function like this:
//export _RVExtension@12
func _RVExtension@12(output *C.char, outputsize
19 matches
Mail list logo
