So... my first question is still actual.
We plan to study source code, but before, maybe. somebody who already know it can tell me - how we can reduce tgtd memory usage?
Thank you!
25.03.2011, в 0:10, Stepan Fedorov написал(а):
>
> OK! I do some tests on my test environment and here is the results:
>
> My target node has 12Gb of memory. I created 300 LUN's on it - tgtd process virtual size become something above 13Gb.
>
> Next, i attach this LUNs on three initiator nodes - 100 LUNs per node.
>
> Now - my task is to initiate some IO on all of this LUNs in parallel, to see - what happen with tgtd.
>
> To do this, i created LVM striped volume (/dev/vbd0/megadisk0) from 100 iSER-attached LUNs on each initiator node.
>
> Next, i run e2fsck /dev/vbd0/megadisk0 on three nodes. During this process, i got messages about IO errors on all LUNs in dmesg on all three nodes, because tgtd segfaults on target node, with this message in dmesg:
> [734121.705847] tgtd[18959]: segfault at 0 ip (null) sp 00007fff04d22118 error 14 in tgtd[400000+4a000]
>
>
> 24.03.2011, в 14:06, FUJITA Tomonori написал(а):
>
>> On Thu, 24 Mar 2011 14:09:14 +0300
>> Степан Фёдоров <stepan.fedorov@xxxxxxxx> wrote:
>>
>>> Hm... i create 666 targets with one LUN per target on node with 12Gb
>>> of memory, and in top i see this:
>>>
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>>
>>> 7862
>>> root 20 0 22.4g 1.6g 1144 S 2 13.4 7:39.18
>>> /usr/sbin/tgtd
>>>
>>> VIRT, and RES values grows while i attach this targets on initiator
>>> node. What will happen, if tgt begin usage of all this memory while
>>> serving it's targets? It will be killed by oom killer?
>>
>> tgtd can avoid oom killer by setting /proc/{pid}/oom_adj.
>>
>>
>>> Ooops. While i write this - on initiator side i got in dmesg a "BUG" message )
>>
>> Needs to report it to open-iscsi mailing list.
>
> Stepan Fedorov
> sf@xxxxxxxx
>
>
>
Stepan Fedorov
sf@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
