On Feb 6, 2008 5:38 PM, Tracy, John <[EMAIL PROTECTED]> wrote: > I checked /var/adm/messages and /var/log/syslog, and didn't see anything > related to > iSCSI in any of those locations. Is there anywhere else I should look for > iscsitgtd logs?
Judging by the code, iscsitgtd logs to /tmp/target_log. -- Regards, Andrey > > Cheers- > John > > > -----Original Message----- > From: Andrey Kuzmin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 06, 2008 9:24 AM > To: Tracy, John > Cc: [email protected] > Subject: Re: iscsitgt becoming very slow after two weeks uptime > > > Date: Tue, 05 Feb 2008 13:34:07 PST > > From: John Tracy <[EMAIL PROTECTED]> > > Subject: Re: [storage-discuss] iscsitgt becoming very slow after two > > weeks uptime > > To: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=UTF-8 > > > > The problem happened again (as expected). I did apply an IDR patch as > > recommended by Sun, > > patch IDR137189-02 for those who may be interested. After issuing a reboot, > > I then started > > hammering away at the iSCSI targets on this box again. These patches seem > > to primarily have > > to do with ZFS items. I'm thinking that this may be off the mark, as even > > while the performance > > is terrible with iSCSI mounted volumes, local IO operations on the box > > utilizing the same ZFS > > pool are as quick as should be expected. > > > > Just out of curiosity, I generated a core of the iscsitgtd and then ran mdk > > against it. This is the result. I'm not sure where to go from here: > > > > gcore 12529 > > gcore: core.12529 dumped > > bash-3.00# mdb core.12529 > > Loading modules: [ ld.so.1 libumem.so.1 libavl.so.1 libc.so.1 > > libnvpair.so.1 libuutil.so.1 ] > <snip> > > > ::findleaks > > CACHE LEAKED BUFCTL CALLER > > 0000000000484028 239 00000000004ab620 iscsi_full_feature+0x365 > > iscsi_full_feature allocates memory for iSCSI Additional Header > Segment, and indeed does not free it up in some cases (see the patch > below). Nonetheless, these leaks are on error handling path and should > not show up during normal operations. Did you notice any iscsitgt > error messages in the log? > > > > ---------------------------------------------------------------------- > > Total 239 buffers, 15296 bytes > > > > > > From what I read, this indicates the operations I'm performing are > > generating quite a few > > memory leaks within the iscsitgtd process. Is my understanding correct? > > > > These statistics are gathered before the box exhibits the problem (within > > an hour of restarting > > iscsitgt). > > -- > Regards, > Andrey > Index: iscsitgtd/iscsi_ffp.c > =================================================================== > --- iscsitgtd/iscsi_ffp.c (revision 945) > +++ iscsitgtd/iscsi_ffp.c (working copy) > @@ -98,6 +98,7 @@ > (void) snprintf(debug, sizeof (debug), > "CON%x Failed to read in AHS", c->c_num); > queue_str(c->c_mgmtq, Q_CONN_ERRS, msg_log, debug); > + free(ahs); > return (False); > } > } > @@ -117,6 +118,8 @@ > "CON%x CRC error: actual 0x%x v. calc 0x%x", > c->c_num, crc_actual, crc_calculated); > queue_str(c->c_mgmtq, Q_CONN_ERRS, msg_log, debug); > + if (ahs != NULL) > + free(ahs); > return (False); > } > } > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
